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

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.

I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple
of these machines were booted with slub_debug=- . They all seemed a bit
slower (based on my watching the updates and not real benchmarks) than with
with the previous debug kernels. It isn't quite to show stopping slow, but
it's getting close. It might be the slowness I see with debugging
kernels for yum updates, is due to a combination of multiple debugging
features rather than a single one.

hello,
Recently my fedora 17 system has a problem in booting. The error is the below:
plymouthd: ply-array.c:82: ply_array_get_size:Assertion `array->element_type==PLY_ARRAY_ELEMENT_TYPE_POINTER || array->element_type==PLY_ARRAY_ELEMENT_TYPE_UINT32` failed
what does it mean?
thomas1997ster

As mentioned in the FUDCon kernel talk, we are trying to figure out
exactly what causes the massive slowdown for some people with debug
kernels. At this point, debug is completely off in the rawhide kernel.
Every update this week will turn on more debug options until we find out
which one is causing the slowdown. For this to work, we need people
testing rawhide proper (not rawhide-nodebug). So please, if you can
update daily and give us feedback when you hit a wall, we would really
appreciate it. Feedback should be sent to kernel(a)lists.fedoraproject.org
Thanks,
Justin