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, 10 months
debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline
by poma
Sound whispers,
WARNING: CPU: 3 PID: 900 at lib/dma-debug.c:593
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel 0000:00:07.0: DMA-API: cpu touching an active dma mapped
cacheline [cln=0x03014000]
CPU: 3 PID: 900 Comm: chronyd Not tainted 3.15.0-0.rc1.git1.1.fc21.i686 #1
Call Trace:
[<c0ae256d>] dump_stack+0x48/0x60
[<c0454402>] warn_slowpath_common+0x82/0xa0
[<c0750b69>] ? debug_dma_assert_idle+0x159/0x1d0
[<c0750b69>] ? debug_dma_assert_idle+0x159/0x1d0
[<c045445e>] warn_slowpath_fmt+0x3e/0x60
[<c0750b69>] debug_dma_assert_idle+0x159/0x1d0
[<c05860b9>] ? anon_vma_prepare+0x29/0x140
[<c057a4ee>] do_wp_page+0xce/0x890
[<c0500045>] ? auditsc_get_stamp+0x45/0x70
[<c057caf2>] handle_mm_fault+0x662/0xb70
[<c0500045>] ? auditsc_get_stamp+0x45/0x70
[<c0aee507>] __do_page_fault+0x1a7/0x5d0
[<c040ace8>] ? sched_clock+0x8/0x10
[<c040ace8>] ? sched_clock+0x8/0x10
[<c04ab036>] ? lock_release_holdtime.part.28+0x96/0xf0
[<c0aee930>] ? __do_page_fault+0x5d0/0x5d0
[<c0aee94a>] do_page_fault+0x1a/0x20
[<c0aeb344>] error_code+0x6c/0x74
[<c07334b6>] ? __put_user_4+0x1a/0x24
[<c048d280>] ? schedule_tail+0x60/0xa0
[<c0af3746>] ret_from_fork+0x6/0x20
---[ end trace d31d73481e988403 ]---
Mapped at:
[<c074ec12>] debug_dma_alloc_coherent+0x22/0x70
[<f812de90>] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
[<f812dfe2>] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
[<f812e3b0>] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
[<f812df23>] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
https://bugzilla.redhat.com/show_bug.cgi?id=1087565
poma
9 years, 7 months
[PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA
by poma
Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP & X550CA, so that the wireless network adapter is enabled.
References:
- asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
http://marc.info/?l=linux-kernel&m=139819918125110
- Ath9k WiFi now disabled by radio killswitch
https://bugzilla.redhat.com/show_bug.cgi?id=1089731
Reported-by: poma <pomidorabelisima(a)gmail.com>
Reported-by: Andreas Utterberg <andreas.utterberg(a)thundera.se>
Tested-by: poma <pomidorabelisima(a)gmail.com>
Tested-by: Andreas Utterberg <andreas.utterberg(a)thundera.se>
Cc: Fedora kernel development <kernel(a)lists.fedoraproject.org>
Cc: Andreas Utterberg <andreas.utterberg(a)thundera.se>
Cc: Josh Boyer <jwboyer(a)fedoraproject.org>
Cc: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
drivers/platform/x86/asus-nb-wmi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..d3641e0 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. X550CA",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X550CA"),
+ },
+ .driver_data = &quirk_asus_x401u,
+ },
+ {
+ .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. X55A",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
@@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. X75VBP",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
+ },
+ .driver_data = &quirk_asus_x401u,
+ },
+ {
+ .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. 1015E",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--
1.9.0
9 years, 10 months
kernel-3.15.0-0.rc3.git1.10.fc21 - noarch
by poma
kernel-3.15.0-0.rc3.git1.10.fc21.noarch.rpm
'noarch', what is it for?
...
Package: kernel-3.15.0-0.rc3.git1.10.fc21.noarch - can't co-install with
kernel-3.15.0-0.rc3.git1.10.fc21.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.15.0-0.rc3.git1.10.fc21 will be installed
--> Processing Dependency: kernel-drivers-uname-r =
3.15.0-0.rc3.git1.10.fc21.x86_64 for package:
kernel-3.15.0-0.rc3.git1.10.fc21.x86_64
--> Processing Dependency: kernel-core-uname-r =
3.15.0-0.rc3.git1.10.fc21.x86_64 for package:
kernel-3.15.0-0.rc3.git1.10.fc21.x86_64
...
...
Package: kernel-3.15.0-0.rc3.git1.10.fc21.noarch - can't co-install with
kernel-3.15.0-0.rc3.git1.10.fc21.i686
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:3.15.0-0.rc3.git1.10.fc21 will be installed
--> Processing Dependency: kernel-drivers-uname-r =
3.15.0-0.rc3.git1.10.fc21.i686 for package:
kernel-3.15.0-0.rc3.git1.10.fc21.i686
--> Processing Dependency: kernel-core-uname-r =
3.15.0-0.rc3.git1.10.fc21.i686 for package:
kernel-3.15.0-0.rc3.git1.10.fc21.i686
...
Thanks.
poma
9 years, 12 months
The nodebug repo has fallen behind
by Bruno Wolff III
The last nodebug kernel was a copy of rc2.git0. Since then, git1, git2 and
git3 kernels have been built for rawhide, but not for the nodebug repo.
10 years
Allwinner Axx mmc support for Fedora kernels
by Hans de Goede
Hi All,
I've prepared a git tree with the minimal sunxi-mmc support so that we
can properly get Fedora to run (headless) on Axx boards. You can
find the patch-set here:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-mmc
This patch set looks larger then it really is as upstream wants the dts
bits cut into quite small patches.
This basically consists of 3 bits:
1) some sunxi-clk driver changes
2) a new sunxi-mmc.c file
3) dts bindings for the above
Note this only touches sunxi specific files. If I get no objections
the next few days I'm going to squash this all into one big sunxi-mmc
patch and add that to the rawhide kernel builds.
Regards,
Hans
10 years
zram module should not be autoloaded
by Reindl Harald
Hi
currently you need to remove the zram module
because it's autoloaded in case you want
to use the zram num_devices-param
maybe it should not be autoloaded implicitly
/usr/sbin/rmmod zram 2> /dev/null > /dev/null
/usr/sbin/modprobe -q zram num_devices=$num_cpus 2> /dev/null > /dev/nul
______________________________________
[root@testserver:~]$ cat /usr/sbin/zramstart
#!/usr/bin/bash
num_cpus=$(grep -c processor /proc/cpuinfo)
[ "$num_cpus" != 0 ] || num_cpus=1
last_cpu=$((num_cpus - 1))
FACTOR=20
[ -f /etc/sysconfig/zram ] && source /etc/sysconfig/zram || true
factor=$FACTOR
memtotal=$(grep MemTotal /proc/meminfo | awk ' { print $2 } ')
mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024))
/usr/sbin/rmmod zram 2> /dev/null > /dev/null
/usr/sbin/modprobe -q zram num_devices=$num_cpus 2> /dev/null > /dev/null
for i in $(seq 0 $last_cpu); do
echo $mem_by_cpu > /sys/block/zram$i/disksize
/usr/sbin/mkswap /dev/zram$i
/usr/sbin/swapon -p 100 /dev/zram$i
done
10 years
3.14 stable branch ETA?
by Conrad Meyer
Hi all,
3.14 gold was released by Linus recently, and comes with some
exciting features (zram, ...). Do we have an anticipated
timeline for rebasing stable F-20 on linux-3.14?
Thanks,
Conrad
10 years
3.15-rc0.git11 scratch build
by Josh Boyer
There's a gcc 4.9 bug right now that prevents the kernel from building
on ARM. Since ARM is a primary arch, it fails the build on x86_64 and
i686 as well. Until gcc is fixed, there won't be any new rawhide
kernels (unless I find a workaround).
I've done a scratch build of the next git snapshot kernel for i686 and
x86_64 here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6725695
NOTE: That hasn't gone through any testing yet. I plan on testing it
in my usual setups tomorrow morning, and I'll report back after. I'm
just posting it now for the anxious and adventurous.
josh
10 years
