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, 6 months
[PATCHSET] utrace for 3.1 kernel
by Oleg Nesterov
Hello.
utrace patches for 3.1 kernel. Untested, will try to do some tests
tomorrow.
I do not want to spam you all and the lists, please look at
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1
Oleg Nesterov (29):
utrace: add utrace_init_task/utrace_free_task calls
tracehooks: add utrace hooks
tracehooks: reintroduce tracehook_consider_fatal_signal()
add utrace hooks into sig_ignored() and recalc_sigpending()
restore the EXEC/EXIT/CLONE utrace hooks
utrace: utrace_report_death() can use task_utrace_struct()
restore the DEATH/REAP utrace hooks
utrace: remove jobctl bits
ptrace: take ->siglock around s/TRACED/RUNNING/
introduce wake_up_quiescent()
introduce ptrace_signal_wake_up()
wait_task_inactive: treat task->state and match_state as bitmasks
introduce TASK_UTRACED state
utrace: use TASK_UTRACED instead of TASK_TRACED
reintroduce tracehook_finish_jctl() as utrace_end_stop()
teach wake_up_quiescent() to do "selective" wake_up
ptrace_stop: do not assume the task is running after wake_up_quiescent()
get_signal_to_deliver: restore/restructure utrace/ptrace signal reporting
utrace_get_signal: s/JOBCTL_STOP_PENDING/JOBCTL_PENDING_MASK/
introduce ptrace_set_syscall_trace()
introduce PT_SYSCALL_TRACE flag
utrace: don't clear TIF_SYSCALL_TRACE if it is needed by ptrace
introduce task_utrace_lock/task_utrace_unlock
teach ptrace_set_syscall_trace() to play well with utrace
introduce PT_SINGLE_STEP and PT_SINGLE_BLOCK
utrace: finish_resume_report: don't do user_xxx_step() if ptrace_wants_step()
ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop()
ptrace_disable: no need to disable stepping
ptrace_report_syscall: check TIF_SYSCALL_EMU
Roland McGrath (1):
utrace core
Documentation/DocBook/Makefile | 2 +-
Documentation/DocBook/utrace.tmpl | 589 +++++++++
arch/s390/kernel/traps.c | 4 +-
arch/x86/kernel/ptrace.c | 1 -
fs/exec.c | 5 +-
fs/proc/array.c | 14 +-
include/linux/ptrace.h | 7 +
include/linux/sched.h | 25 +-
include/linux/signal.h | 2 +
include/linux/tracehook.h | 53 +-
include/linux/utrace.h | 773 ++++++++++++
init/Kconfig | 9 +
kernel/Makefile | 1 +
kernel/exit.c | 5 +
kernel/fork.c | 9 +
kernel/ptrace.c | 57 +-
kernel/sched.c | 2 +-
kernel/signal.c | 97 ++-
kernel/utrace.c | 2461 +++++++++++++++++++++++++++++++++++++
19 files changed, 4062 insertions(+), 54 deletions(-)
create mode 100644 Documentation/DocBook/utrace.tmpl
create mode 100644 include/linux/utrace.h
create mode 100644 kernel/utrace.c
11 years, 10 months
[PATCH F-14] bz#573210: ptrace-utrace: fix PTRACE_GETEVENTMSG(pid) in LXC
by Oleg Nesterov
https://bugzilla.redhat.com/show_bug.cgi?id=573210
ptrace_report_clone() uses child->pid, this is obviously wrong unless
the tracer is from the global namespace. Change it to use task_pid_vnr().
This is still not right, we should use the tracer's namespace, not
parent's. But this matches upstream, and at least this works if they
are from the same namespace.
Reported-by: Robin Green <greenrd(a)greenrd.org>
Signed-off-by: Oleg Nesterov <oleg(a)redhat.com>
--- a/kernel/ptrace-utrace.c
+++ b/kernel/ptrace-utrace.c
@@ -403,7 +403,7 @@ static u32 ptrace_report_clone(u32 actio
return UTRACE_RESUME;
set_stop_code(ctx, event);
- ctx->eventmsg = child->pid;
+ ctx->eventmsg = task_pid_vnr(child);
/*
* We shouldn't stop now, inside the do_fork() path.
* We will stop later, before return to user-mode.
12 years, 3 months
[PATCH 0/2] cifs: fix a couple of mount time problems
by Jeff Layton
We've had a number of panics reported by people using cifs mounts on
F15. See the following reported bugs:
727927
731278
732934
I'd like to see both of the following patches added to 2.6.40.3
and above until they make it into the stable series. The second
may also be appropriate for F16, but it may be simpler to just
wait for the stable series to catch up there.
The patches are pretty straightforward fixes, let me know if
anything with them isn't clear.
Pavel Shilovsky (1):
CIFS: Fix ERR_PTR dereference in cifs_get_root
Steve French (1):
[CIFS] possible memory corruption on mount
fs/cifs/cifsfs.c | 10 ++++++----
fs/cifs/connect.c | 3 ++-
2 files changed, 8 insertions(+), 5 deletions(-)
--
1.7.6
12 years, 3 months
3.1. kernel
by Genes MailLists
Dave - any chance you'd put together an F15 2.6.41 based on 3.1?
gene
12 years, 3 months
2.6. 40-3 / F15
by Genes MailLists
Thanks for working on this 3.0.x for f15.
Just to let you know I've been testing 2.6.40.3-0.fc15.x86_64 (for a
few hours) and so far its working well (lenovo W520 I7 sandy bridge
laptop). Will keep you posted of any issues should they arise.
Thanks !!
gene
12 years, 3 months
3.1 pushed to f16
by Josh Boyer
Hi All,
Moving forward with our plan to release Fedora 16 with the 3.1 kernel, I
pushed 3.1-rc2 into the F16 branch this morning. Dave and I have both
been running it in rawhide for a bit now, and it's been fairly stable.
There will, of course, be bugs but getting some testing on the rc's will
hopefully allow us to get them resolved before 3.1 final is out. I will
submit a build for f16 updates-testing a bit later this week.
NOTE: This will not impact the Alpha release. That will go out with
3.0.
josh
12 years, 3 months
Experimental kernels with inode-uprobes, without utrace
by Josh Stone
Hi all,
To facilitate systemtap testing and development on the new inode-based
uprobes, I've build and posted a few kernels with that patch applied,
and without utrace. I also added a few exports for stap module use.
The builds and an appropriate yum repo file are here:
http://repos.fedorapeople.org/repos/jistone/kernel-uprobes/
This is currently using the June 7 patchset from Srikar.
https://lkml.org/lkml/2011/6/7/232
http://git.kernel.org/?p=linux/kernel/git/srikar/linux-uprobes.git
I only built for f15 and f16, as those 3.0(ish) kernels patch cleanly.
In 3.1-rc there are conflicts in the perf parts, so I'll probably just
wait for the next update from Srikar.
It's also not the full complement of kernel variations, as I quickly hit
my quota thanks to debuginfo size. I posted kernel-PAE.i686,
kernel.x86_64, and their supporting packages.
We're not ready for prime-time yet, but hopefully this is useful to
anyone who wants to try the new uprobes. Most of the issues I mentioned
in my previous mail still stand. Some of that will depend on PR10994,
which David is working on, and some will just need this new uprobes to
redevelop features that the old type had.
http://sourceware.org/ml/systemtap/2011-q2/msg00206.html
http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=shortlog;h=refs/he...
http://sourceware.org/bugzilla/show_bug.cgi?id=10994
Let me know if you see any issues...
Thanks,
Josh
12 years, 3 months
[RFC v2 00/19] utrace for 3.0 kernel
by Oleg Nesterov
Another attempt. This version tries to decouple utrace and ptrace.
This way it is much simpler to follow the upstream changes, afaics.
TODO:
- The single-stepping updates in ptrace_resume() can race
with utrace_reset()->user_disable_single_step().
This was fixed by 20/20, but I noticed that this patch
is buggy right before sending.
- Perhaps PTRACE_SYSEMU/TIF_SYSCALL_EMU logic was broken,
I need to recheck.
- Testing.
Oleg.
12 years, 4 months
2.6.40 ecryptfs oops (Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)))
by Michał Piotrowski
W dniu 12 lipca 2011 22:45 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
> I tested it, but it still corrupts data. On Thursday I'll do more
> tests.
Sorry for the nearly month delay :)
Today I tried to copy a file over samba to my encrypted dir and
operation still fails.
When I tried to copy a file from other dir on the same machine to my
encrypted dir I get this oops
[41829.771957] ecryptfs_encrypt_page: Error attempting to write lower
page; rc = [-28]
[41829.772174] ecryptfs_writepage: Error encrypting page (upper index
[0x000000000003598f])
[41829.772602] ------------[ cut here ]------------
[41829.772701] kernel BUG at fs/ecryptfs/read_write.c:47!
[41829.772789] invalid opcode: 0000 [#1] SMP
[41829.772881] CPU 0
[41829.772888] Modules linked in: ecryptfs smsc47m192 hwmon_vid
smsc47m1 coretemp serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support
r8169 mii sata_sil i915 drm_kms_helper drm i2c_algo_bit i2c_core video
[last unloaded: scsi_wait_scan]
[41829.773371]
[41829.773381] Pid: 10839, comm: flush-ecryptfs- Not tainted
2.6.40-4.fc15.x86_64 #1 /D945GCLF2
[41829.773381] RIP: 0010:[<ffffffffa013a218>] [<ffffffffa013a218>]
ecryptfs_write_lower+0x26/0x7d [ecryptfs]
[41829.773381] RSP: 0018:ffff88007b2059e0 EFLAGS: 00010246
[41829.773381] RAX: 0000000000035990 RBX: ffff880079f14400 RCX: 0000000000001000
[41829.773381] RDX: 0000000000001000 RSI: ffff880079e98000 RDI: ffff880079f14400
[41829.773381] RBP: ffff88007b205a10 R08: 0000000000001000 R09: ffff88007b205990
[41829.773381] R10: ffff880079c3b888 R11: ffff880079e98ff0 R12: 0000000000000000
[41829.773381] R13: ffffea0001aab140 R14: ffffea0000829250 R15: ffff880079f14688
[41829.773381] FS: 0000000000000000(0000) GS:ffff88007f200000(0000)
knlGS:0000000000000000
[41829.773381] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[41829.773381] CR2: 00007f52ddb57000 CR3: 0000000037a06000 CR4: 00000000000006f0
[41829.773381] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[41829.773381] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[41829.773381] Process flush-ecryptfs- (pid: 10839, threadinfo
ffff88007b204000, task ffff88007b865cc0)
[41829.773381] Stack:
[41829.773381] ffff88007b2059f0 0000000035992000 0000000000000000
ffff880079f14400
[41829.773381] 0000000000000000 ffffea0001aab140 ffff88007b205a60
ffffffffa013b5a1
[41829.773381] ffffea0000829288 ffff880079e98000 ffff88007b205a80
ffffea0000829250
[41829.773381] Call Trace:
[41829.773381] [<ffffffffa013b5a1>] ecryptfs_encrypt_page+0xeb/0x151 [ecryptfs]
[41829.773381] [<ffffffffa0139b72>] ecryptfs_writepage+0x36/0x78 [ecryptfs]
[41829.773381] [<ffffffff810e353d>] __writepage+0x15/0x2e
[41829.773381] [<ffffffff810e3363>] write_cache_pages+0x203/0x33f
[41829.773381] [<ffffffff810e3528>] ? set_page_dirty_lock+0x33/0x33
[41829.773381] [<ffffffff810e34df>] generic_writepages+0x40/0x56
[41829.773381] [<ffffffff810e4066>] do_writepages+0x28/0x2a
[41829.773381] [<ffffffff8114488d>] writeback_single_inode+0xb2/0x1bc
[41829.773381] [<ffffffff81144bdc>] writeback_sb_inodes+0xcd/0x161
[41829.773381] [<ffffffff81144fac>] writeback_inodes_wb+0x119/0x12b
[41829.773381] [<ffffffff811451a3>] wb_writeback+0x1e5/0x356
[41829.773381] [<ffffffff810e391c>] ? global_dirty_limits+0x2b/0xd1
[41829.773381] [<ffffffff8114548a>] wb_do_writeback+0x176/0x1a9
[41829.773381] [<ffffffff814b6ffa>] ? _raw_spin_lock_irqsave+0x12/0x2f
[41829.773381] [<ffffffff81145538>] bdi_writeback_thread+0x7b/0x1f8
[41829.773381] [<ffffffff811454bd>] ? wb_do_writeback+0x1a9/0x1a9
[41829.773381] [<ffffffff8106fd0b>] kthread+0x84/0x8c
[41829.773381] [<ffffffff814be8e4>] kernel_thread_helper+0x4/0x10
[41829.773381] [<ffffffff8106fc87>] ? kthread_worker_fn+0x148/0x148
[41829.773381] [<ffffffff814be8e0>] ? gs_change+0x13/0x13
[41829.773381] Code: 01 d8 5b 5d c3 55 48 89 e5 41 55 41 54 53 48 83
ec 18 66 66 66 66 90 48 83 bf 80 02 00 00 00 48 89 55 d8 48 89 fb 48
89 ca 75 02 <0f> 0b 65 4c 8b 24 25 48 cd 00 00 4d 8b ac 24 48 e0 ff ff
49 c7
[41829.773381] RIP [<ffffffffa013a218>]
ecryptfs_write_lower+0x26/0x7d [ecryptfs]
[41829.773381] RSP <ffff88007b2059e0>
[41829.778779] ---[ end trace 32ff51ffa8acda79 ]---
I'm using
ecryptfs-utils-87-8.fc15.x86_64
kernel-2.6.40-4.fc15.x86_64
> Data corruption does not happen always, so now I'm not too sure
> whether this has to do with eCryptfs itself. May simply not happened
> when I tested samba on not encrypted filesystem.
>
--
Best regards,
Michal
http://eventhorizon.pl/
12 years, 4 months
