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
3.9 merge window kernels
by Josh Boyer
Just a quick heads up that the 3.9 merge window kernels are being built
in rawhide now. I've tried to at least test boot kernels on my machine
before submitting them to koji, but testers beware. Merge window
kernels can be tricky.
ARM people: the -git4 kernel build has the big ARM merge contained in
it. I've tried to go through and make a reasonable estimation of what
all the ARM related config options should be set to, but you really need
to look those over. Also... the config file setup is confusing,
particularly config-armv7. That seems to be used by only
kernel-armv7/kernel-armv7hl but not by the omap and tegra armv7 configs.
I think that is leading to some duplication of config settings. Anyway,
look it over please.
PPC/S390x people: You're set. Your architectures are apparently boring
and predictable, so there were no config file changes needed.
josh
10 years, 3 months
Problems with git5 on one of three machines
by Bruno Wolff III
I have git5 running OK on two machines, but on the third machine I get
tracebacks without apparent progress. The console shows on the order of
one traceback a minute and after about 15 minutes without getting X,
I went back to git3. Since there are some pending fixes, I'll wait until
the next build before trying to report the problem.
10 years, 3 months
enable new hw features in f18 kernel on s390x
by Dan Horák
diff --git a/config-s390x b/config-s390x
index 41e41c5..3abce9a 100644
--- a/config-s390x
+++ b/config-s390x
@@ -244,9 +244,9 @@ CONFIG_ETHERNET=y
CONFIG_BPF_JIT=y
# CONFIG_TRANSPARENT_HUGEPAGE is not set
-# CONFIG_SCM_BUS is not set
-# CONFIG_EADM_SCH is not set
-# CONFIG_SCM_BLOCK is not set
-# CONFIG_SCM_BLOCK_CLUSTER_WRITE is not set
+CONFIG_SCM_BUS=y
+CONFIG_EADM_SCH=m
+CONFIG_SCM_BLOCK=m
+CONFIG_SCM_BLOCK_CLUSTER_WRITE=y
# CONFIG_S390_PTDUMP is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
10 years, 3 months
new options to enable in s390x kernels
by Dan Horák
please add these options to the s390x config (f18 and up)
CONFIG_EADM_SCH=m CONFIG_SCM_BUS=y CONFIG_SCM_BLOCK=m
CONFIG_SCM_BLOCK_CLUSTER_WRITE=y
those are for new features available in new kernels
and for 3.8 kernels I think we should enable
CONFIG_PCI=y
unless it will be inherited from the generic config
yes, PCI is coming also to s390 :-)
Dan
10 years, 3 months
Issue with 3.8.0-0.rc5.git2.1.fc19 and rv280 based video card
by Bruno Wolff III
I tried 3.8.0-0.rc5.git2.1.fc19 on three systems. One without X, one using
an rv530 based video card and one using an rv280 based video card. The
system using the rv280 based card has either extremely slow graphics or
busted graphics. The other two seem to function normally. On the rv280
based system it takes longer than normal to sort of get the gdm screen up.
It comes up without the background graphic and when I click on the user
it doesn't seem to return a password prompt in a reasonable time. C-A-F2
still works and I can use a vt normally. In one case when I switched back
I saw the background image. So it may be that video is just running really
slow.
Things work OK with 3.8.0-0.rc5.git1.1.fc19.
When there is a nodebug version of that kernel out, I'll try it to see
if it is the ATOMIC_SLEEP debugging or some other change in the kernel
causing the problem.
10 years, 4 months
Debug options update and 3.8-rc6
by Josh Boyer
Hi All,
Thanks to testing from several people we seem to be narrowing down on
which debug options are causing the biggest performance hit in rawhide
kernels. As of right now, SLUB_DEBUG is the worst offender.
Fortunately, you can disabled that via the slub_debug=- command line
switch. The other option that causes a big hit is PROVE_RCU, but by
itself it isn't a major issue. Combined with SLUB_DEBUG though, it will
really impact things.
I've started collecting some of these test results here:
https://fedoraproject.org/wiki/KernelDebugOptions
I'll continue to update that as people provide results.
As a note, the 3.8-rc6 kernel will not have debug options disabled. We
really only have a few major options left to get through, so we'll
continue with turning them on. The nodebug rawhide repo will contain a
build without the debug options set as usual. I expect that -rc7 will
go back to the normal method of doing things.
If you have questions/comments please drop us a line on the list!
josh
10 years, 4 months
