Re: [PATCH] x86_64: fix delayed signals

[Elias Oltmanns <eo@nebensachen.de>]

Ingo Molnar <mingo@elte.hu> wrote:
> * Roland McGrath <roland@redhat.com> wrote:
>
>> On three of the several paths in entry_64.S that call 
>> do_notify_resume() on the way back to user mode, we fail to properly 
>> check again for newly-arrived work that requires another call to 
>> do_notify_resume() before going to user mode.  These paths set the 
>> mask to check only _TIF_NEED_RESCHED, but this is wrong.  The other 
>> paths that lead to do_notify_resume() do this correctly already, and 
>> entry_32.S does it correctly in all cases.
>
> nice find! Roland, is this related to the thread started by Elias 
> Oltmanns yesterday:
>
>     http://lkml.org/lkml/2008/7/10/57
>
> which is also related to the thread started by Edwin Török:
>
>     http://lkml.org/lkml/2008/6/28/50
>
> ? The weight of complains seems to be on the 64-bit side, in those 
> threads 32-bit systems seem to be implicated as well by latencytop. 
> Perhaps the 64-bit delays are related to the bug you fix and we could 
> chalk up the 32-bit delays to IO delays?

Since I'm using a 32-bit machine, this patch isn't going to solve my
particular problem. Still, I'm glad to hear that someone is looking at
the assembly bits related to signal handling right now because that's
precisely the part where I gave up to figure out for myself how signal
handling works in the kernel.

As for delayed signal handling on 32-bit platforms due to heavy disk
I/O, I'm still reluctant to accept that signals should be delayed that
much even though everything else that is not related to disk I/O works
perfectly well. Now that I've seen some documentation for ftrace, I'll
give it a go and try produce some helpful data. However, I'm rather busy
right now and may not be able to do so before next week.

Regards,

Elias