lkml.org 
[lkml]   [2011]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/5] Signal scalability series
    On 09/30, Oleg Nesterov wrote:
    >
    > On 09/30, Matt Fleming wrote:
    > >
    > > However, it's a good first step and
    > > hopefully by keeping it relatively simple it'll make it easier to
    > > review.
    >
    > Cough. I'll try to read this series next week, but currently I feel
    > I will never able to understand this code. It surely compliacates
    > things a lot.
    >
    > But. All I can do is to _try_ to check this series from the correctness
    > pov. I can't believe (at least at first glance) this worth the trouble,
    > but otoh I won't argue unless I'll find the bugs.
    >
    > > arch/ia64/kernel/signal.c | 4 +-
    > > drivers/block/nbd.c | 2 +-
    > > drivers/usb/gadget/f_mass_storage.c | 2 +-
    > > drivers/usb/gadget/file_storage.c | 2 +-
    > > fs/autofs4/waitq.c | 5 +-
    > > fs/exec.c | 17 +-
    > > fs/jffs2/background.c | 2 +-
    > > fs/ncpfs/sock.c | 2 +
    > > fs/proc/array.c | 2 +
    > > fs/signalfd.c | 11 +-
    > > include/linux/init_task.h | 4 +
    > > include/linux/sched.h | 23 +-
    > > kernel/exit.c | 29 +-
    > > kernel/fork.c | 4 +
    > > kernel/freezer.c | 10 +-
    > > kernel/kmod.c | 8 +-
    > > kernel/posix-timers.c | 5 +-
    > > kernel/ptrace.c | 68 ++--
    > > kernel/signal.c | 737 +++++++++++++++++++++++++++--------
    > > net/9p/client.c | 6 +-
    > > net/sunrpc/svc.c | 3 -
    > > security/selinux/hooks.c | 11 +-
    > > 22 files changed, 677 insertions(+), 280 deletions(-)
    >
    > And, this patch adds 4 new locks:
    >
    > sighand_struct->action_lock
    >
    > signal_struct->ctrl_lock
    > signal_struct->shared_siglock
    >
    > task_struct->siglock
    >
    > Nice ;) For what? This should be justified, imho.

    Yes. I did the quick and dirty check (under kvm),

    Before this series:

    [tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m2.451s
    user 0m0.350s
    sys 0m2.097s
    [tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m2.475s
    user 0m0.357s
    sys 0m2.117s
    [tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m2.443s
    user 0m0.330s
    sys 0m2.113s

    After:

    tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m3.194s
    user 0m0.283s
    sys 0m2.910s
    [tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m3.212s
    user 0m0.357s
    sys 0m2.853s
    [tst@myhost ~]$ time perl -wle '$SIG{HUP}=sub{}; kill HUP, $$ for 1..100_000'

    real 0m3.196s
    user 0m0.350s
    sys 0m2.846s

    Doesn't like very good (may be only under kvm?). In fact I am really
    surprised, I didn't expect the difference will be that noticeable.

    Yes, yes, I understand that your goal is scalability, but still.

    Oleg.



    \
     
     \ /
      Last update: 2011-09-30 21:01    [W:0.031 / U:61.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site