fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 4 months
Oct. Fedora Kernel Patch Report
by Josh Boyer
Here's this months Fedora kernel report. I intended to get it out
last week, but Greg keeps releasing new stable kernels. Given he's at
KS right now, I'll finally get it written before another release comes
out.
I've skipped the patches we tend to carry for default option changes
and such. If people really want me to keep listing those, I'd be
happy to.
josh
Patches we currently have on top of 3.11.6:
tcp-fix-incorrect-ca_state-in-tail-loss-probe.patch (rhbz 989251)
- Backport of upstream commit 031afe4990a7c9dbff41a3a742c44d3e740ea0a1
fix-buslogic.patch (rhbz 1015558)
- Backport of upstream commit 6541932ea2f7de0b0c5203decf666b143ad5fa33
rt2800usb-slow-down-TX-status-polling.patch (rhbz 984696)
- Still pending upstream. Fixes
https://bugzilla.kernel.org/show_bug.cgi?id=62781
btrfs-relocate-csums-properly-with-prealloc-ext.patch (rhbz 1011714)
- Still pending upstream
fix-radeon-sound.patch (rhbz 1010679)
- Backport of:
062c2e4363451d49ef840232fe65e8bff0dde2a5
e7d12c2f98ae1e68c7298e5028048d150fa553a1
ee0fec312a1c4e26f255955da942562cd8908a4b
b852c985010a77c850b7548d64bbb964ca462b02
- fixes https://bugs.freedesktop.org/show_bug.cgi?id=69675
cpupower-Fix-segfault-due-to-incorrect-getopt_long-a.patch (rhbz 1000439)
- Queued for next upstream release I believe. Fixes a segfault in cpupower
dm-cache-policy-mq_fix-large-scale-table-allocation-bug.patch (rhbz 993744)
- Still pending upstream
0001-iwlwifi-don-t-WARN-on-host-commands-sent-when-firmwa.patch (rhbz 896695)
- Backport of commit 8ca95995e64f5d270889badb3e449dca91106a2b
0002-iwlwifi-don-t-WARN-on-bad-firmware-state.patch (rhbz 896695)
- Still pending upstream
vfio-iommu-Fixed-interaction-of-VFIO_IOMMU_MAP_DMA.patch (rhbz 998732)
- Still pending upstream
iommu-Remove-stack-trace-from-broken-irq-remapping-warning.patch (rhbz 982153)
- Still pending upstream
netfilter-nf_conntrack-use-RCU-safe-kfree-for-conntr.patch
- Backport of commit c13a84a830a208fb3443628773c8ca0557773cc7
rt2800-add-support-for-rf3070.patch (rhbz 974072)
- Actually I'm unsure of what the upstream status on this one is.
elevator-Fix-a-race-in-elevator-switching-and-md.patch
elevator-acquire-q-sysfs_lock-in-elevator_change.patch (rhbz 902012)
- I believe these are both queued for the next upstream release
bonding-driver-alb-learning.patch (rhbz 971893)
- Backport of commit 7eacd03810960823393521063734fc8188446bca
Revert-rt2x00pci-Use-PCI-MSIs-whenever-possible.patch
- Backport of commit dfb6b7c109a7f98d324a759599d1b4616f02c79f
ntp-Make-periodic-RTC-update-more-reliable.patch (rhbz 985522)
- I believe this is queued in John Stultz's tree for 3.13
ansi_cprng-Fix-off-by-one-error-in-non-block-size-request.patch (rhbz
1007690 1009136)
- Fixes CVE-2013-4345
media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch
(rhbz 963715)
- Backport of commit b43ea8068d2090cb1e44632c8a938ab40d2c7419
iwl3945-better-skb-management-in-rx-path.patch
iwl4965-better-skb-management-in-rx-path.patch (rhbz 977040)
- Backport of commits 45fe142cefa864b685615bcb930159f6749c3667 and
c1de4a9557d9e25e41fc4ba034b9659152205539
ath9k_rx_dma_stop_check.patch (rhbz 892811)
- Fixes some DMA issue on specific hardware. Taken from
https://dev.openwrt.org/browser/trunk/package/mac80211/patches/552-ath9k_...
secure-modules.patch
modsign-uefi.patch
sb-hibernate.patch
sysrq-secure-boot.patch
- Fedora secure boot support.
- Dear Matthew, this is your fault. Run sed already and get a new set out.
keys-expand-keyring.patch
keys-krb-support.patch
keys-x509-improv.patch
keyring-quota.patch
- I believe these are all now queued for 3.13 in James Morris' tree.
9 years, 10 months
fix building crash driver on s390
by Dan Horák
Hi,
currently the crash driver is disabled in rawhide, but enabled as
module in f20 and stabilization branch. The following snippet make it
build on s390
diff -up a/arch/s390/mm/maccess.c.crash b/arch/s390/mm/maccess.c
--- a/arch/s390/mm/maccess.c.crash 2013-11-26 10:51:55.188222879 -0500
+++ b/arch/s390/mm/maccess.c 2013-11-26 10:52:43.718223592 -0500
@@ -228,3 +228,6 @@ void unxlate_dev_mem_ptr(unsigned long a
if ((void *) addr != buf)
free_page((unsigned long) buf);
}
+
+EXPORT_SYMBOL(xlate_dev_mem_ptr);
+EXPORT_SYMBOL(unxlate_dev_mem_ptr);
I think it should get appended to the crash driver patch.
Dan
9 years, 10 months
another qxl patch
by David Airlie
Hi guys,
this is going upstream but its a nasty leak inside a VM so it might be nice to get it into Fedora tree before it goes through stable.
Dave.
9 years, 10 months
[help needed] how to recompile a single kernel module
by Christian Stadelmann
Hi
I'd like to run a test provided by a kernel developer (diff/patch file
for a single .c file in ath9k module) [1]
How do I do that?
I tried these steps (following [2] though the module is not out of
tree):
1. installed kernel-devel package
2. got a git pull on Linus' kernel git from [3]
3. rebased the kernel to v3.11 (the one I use)
4. cd'ed to drivers/net/wireless/ath/ath9k/
5. applied the changes from [1]
6. ran
$ make -C /lib/modules/3.11.9-300.fc20.x86_64/build/ M=`pwd` modules
(compiled successfully)
7. ran
$ sudo make -C /lib/modules/3.11.9-300.fc20.x86_64/build/ M=`pwd`
modules_install
output (I don't really understand that)
~~~~~
make: Entering directory `/usr/src/kernels/3.11.9-300.fc20.x86_64'
INSTALL /home/christian/src/KERNEL/linux/drivers/net/wireless/ath/ath9k/ath9k.ko
Can't read private key
INSTALL /home/christian/src/KERNEL/linux/drivers/net/wireless/ath/ath9k/ath9k_common.ko
Can't read private key
INSTALL /home/christian/src/KERNEL/linux/drivers/net/wireless/ath/ath9k/ath9k_htc.ko
Can't read private key
INSTALL /home/christian/src/KERNEL/linux/drivers/net/wireless/ath/ath9k/ath9k_hw.ko
Can't read private key
DEPMOD 3.11.9-300.fc20.x86_64
make: Leaving directory `/usr/src/kernels/3.11.9-300.fc20.x86_64'
~~~~~
8. ran (with output)
# modprobe -r ath9k_htc
rmmod ath9k_htc
rmmod mac80211
rmmod ath9k_common
rmmod ath9k_hw
rmmod ath
rmmod cfg80211
and made sure that
# lsmod | grep ath9k
listed no more modules
9. loaded cfg80211 and ath using modprobe (ath9k module requires them)
# modprobe cfg80211
# modprobe ath
# modprobe mac80211
10. tried to load newly built ath9k modules
(from /usr/lib/modules/3.11.9-300.fc20.x86_64/extra where the *.ko files
were installed to in step 7. )
# modprobe -a ./ath9k*
builtin ./ath9k_common.ko
builtin ./ath9k_htc.ko
builtin ./ath9k_hw.ko
builtin ./ath9k.ko
This looks very strange to me.
I tried to manually insert those modules using insmod (according to the
dependencies listet in $ modinfo).
# insmod ./ath9k_hw.ko
# insmod ./ath9k_common.ko
and so on worked fine.
Did I do it right? Is 10. a bug?
regards
Chris
[1] https://bugzilla.kernel.org/show_bug.cgi?id=61111
[2]
https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_Only_Ker...
Additional info:
$ uname -a
Linux chstpc-2 3.11.9-300.fc20.x86_64 #1 SMP Wed Nov 20 22:23:25 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
before changing anything:
$ lsmod | grep ath
ath9k_htc 65868 0
ath9k_common 13503 1 ath9k_htc
ath9k_hw 439078 2 ath9k_common,ath9k_htc
ath 23142 3 ath9k_common,ath9k_htc,ath9k_hw
mac80211 564847 1 ath9k_htc
cfg80211 460310 3 ath,mac80211,ath9k_htc
9 years, 10 months
[PATCH] x86_64-generic - remove duplicate options
by Dan Horák
---
config-x86_64-generic | 5 -----
1 file changed, 5 deletions(-)
diff --git a/config-x86_64-generic b/config-x86_64-generic
index 99e5c5f..9920571 100644
--- a/config-x86_64-generic
+++ b/config-x86_64-generic
@@ -151,11 +151,6 @@ CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NTB=m
CONFIG_NTB_NETDEV=m
-CONFIG_SFC=m
-CONFIG_SFC_MCDI_MON=y
-CONFIG_SFC_SRIOV=y
-CONFIG_SFC_PTP=y
-
# 10GigE
#
CONFIG_IP1000=m
--
1.8.1.4
9 years, 10 months
update config for s390x - 2
by Dan Horák
diff --git a/config-s390x b/config-s390x
index f9f1f82..6f3d325 100644
--- a/config-s390x
+++ b/config-s390x
@@ -265,6 +266,8 @@ CONFIG_SCM_BLOCK_CLUSTER_WRITE=y
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_PTP_1588_CLOCK is not set
+# CONFIG_PPS is not set
# CONFIG_PHYLIB is not set
# CONFIG_ATM_DRIVERS is not set
more unneeded drivers, please apply to both master and stabilization
branches
Dan
9 years, 10 months
[PATCH] update config for s390x
by Dan Horák
---
config-s390x | 1 +
1 file changed, 1 insertion(+)
diff --git a/config-s390x b/config-s390x
index f9f1f82..59f7604 100644
--- a/config-s390x
+++ b/config-s390x
@@ -247,6 +247,7 @@ CONFIG_SCM_BLOCK_CLUSTER_WRITE=y
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
+# CONFIG_SERIO is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_AUXDISPLAY is not set
--
1.8.1.4
9 years, 10 months
Product lifecycles and kernel impacts
by Josh Boyer
Hi All,
I've seen a lot of discussion around release cycles and lifetimes.
I've not heard any specific requests for what impacts any of the
current ideas would have to the kernel, but that doesn't mean they
won't be coming. We should probably start thinking about various
things we can support today, what we could possibly support in the
future, and what we'd need to do it. I've CC'd the Product liaisons
so they can see this. Please keep them on CC.
The first scenario I can think of is probably some kind of "long-term"
release. Exactly what long-term means here is undefined, but we
already support a Fedora release for 13 months or so. We do that
today with rolling kernel releases. We could possibly continue, but I
expect the Products to desire something more "stable".
What that implies is that we'd likely need to base on an upstream
longterm kernel. That means:
1) No new kernel features.
2) No new hardware enablement outside of things acceptable for an
upstream longterm commit (basically just adding a new USB/PCI id to an
existing driver).
3) Bugfixes will primarily come from the upstream longterm tree
4) There will be no alternative kernels supported on the Fedora
longterm release.
5) There are no guarantees on bugfixes, response time, etc.
If any of the above are desired, people are better off picking an
Enterprise distro where you have contracted support.
So if that's the case, the feasibility of this is going to hinge a lot
on timing. I would think from a kernel perspective we'd know up-front
when a Fedora longterm was going to happen, and we'd try and align
that release with the newest official longterm stable kernel. Those
are maintained for 2 years, which seems to be a good fit for a Fedora
longterm release. Any longer than that and you're back in the
Enterprise space again.
The second scenario I can think of is products with mismatched release
cycles. E.g. Server doing a 2 year longterm and developing the
Server.next release on top of Base, which releases every 6 months. Or
Workstation doing a release once a year while Base moves every 6
months. Etc. It's hard to come up with a concrete scenario since
none of the products have gotten this far. It's worth noting that
FESCo is basically disallowing this for the first releases, so this is
a secondary concern.
I would propose that for Base, we continue our current method of
rebasing with each kernel release. That has been working very well
for the past few Fedora releases, and gets us the most "bang for the
buck" in terms of features, hardware support, and fixes. A year long
release for e.g. Workstation would likely also desire the newer
support and features, so they could probably just update their kernel
in the same way. This keeps our maintenance costs down to today's and
gives products flexibility.
In the Server LTS + Server.next development scenario, I would expect
the LTS to use the longterm kernel as suggested above which means
whenever they cut over to LTS mode it would need to coincide with an
upstream longterm kernel. That would be something we have to watch
and plan for. Server.next would continue to use Base until it was
ready to cut over and repeat. I hope that makes sense.
In terms of people, the only major change I see would be the longterm
addition. That might be something we can tuck, but having additional
QA and maintainer resources would allow us to cover development and
support better. If there was any major deviation in which kernel was
used in the various products, we'd likely need either the Product
teams themselves to pick up maintenance or additional people on the
kernel team to handle that. The desire here is to keep the kernel
common among as many Products and releases as we can.
This is mostly just some thoughts I've had on the topics so far. Let
me know what you all are thinking and please ask questions or propose
alternatives as you see fit.
josh
9 years, 10 months
[PATCH 0/3] NFS: Eliminating the Annoying 15sec Delay with NFS mounts.
by Steve Dickson
As I'm sure you've notice the 15sec delay on all NFS mounts.
This is because the kernel now tries to see if it should
use Kerberos in the mount setup. If Kerberos is not set up
(aka rpc.gssd is not running) it takes the kernel 15sec
to figure that out (aka the upcall times out).
The current workaround is to start rpc.gssd, but again,
if Kerberos is not set up, rpc.gssd spews tons of message
in /var/log/messages for every mount. Plus putting
a user level daemon in the mount path is and never
was a good idea... IMHO...
Jeff Layton (jlayton(a)redhat.com) has come up with
some kernel patches what will detect whether the rpc.gssd
daemon is or is not running. When rpc.gssd is not
running the mount continues with no delay. I've
ported them to both F19 and F20.
Now, These patches are working their way upstream atm and
the final version could be slightly different than
these... I doubt it... But until then... The 15 sec
delay will be dead! Thank very much Jeff Layton!!!
steved.
9 years, 10 months
