Re: [RFC][PATCH] signals: don't copy siginfo_t on dequeue

[Oleg Nesterov]

On 02/26, Vegard Nossum wrote:
>
> 2009/2/26 Ingo Molnar <mingo@xxxxxxx>:
> >
> > I.e. shouldnt we have seen a speedup, due to not having to copy
> > the siginfo structure?

I am puzzled by these numbers too. I can't understand how this patch
can make any difference.

> Actually, no. Because copy_siginfo() does not copy the whole (128
> byte) structure if the signal was generated by the user, just probably
> the first 24 bytes or so. So I would expect the "kernel generated
> signal" path to be faster, but that is not tested by my SIGUSR test.
>
> Besides, I think there is a small overhead in now having an extra
> level of indirection for getting our hands on the signal number.

But this all is nothing compared to the "real work" we have to do
in order to handle the signal? setup_rt_frame, sys_rt_sigreturn...

> But we might able to speed up the user->user case a little bit by
> fixing sys_kill() not to use copy_siginfo() too.

Yes. It would really, really nice to preallocate siginfo in sys_kill/etc
and avoid the GFP_ATOMIC allocation in send_signal().

Unfortunaltely, this is not easy too. Because we can send the signal
to pgrp or to all tasks.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/