Re: [Lse-tech] Re: scalability of signal delivery for Posix Threads

[Ray Bryant]

Matthew Wilcox wrote:
> On Mon, Nov 22, 2004 at 09:51:15AM -0600, Ray Bryant wrote:
>
> > Since signals are sent much more often than sigaction() is called, it would
> > seem to make more sense to make sigaction() take a heavier weight lock of
> > some kind (to update the signal handler decription) and to have the signal
> > delivery mechanism take a lighter weight lock.  Making 
> > current->sighand->siglock a rwlock_t really doesn't improve the situation
> > much, since cache line contention is just a severe in that case (if not 
> > worse) than it is with the current definition.
>
>
> What about RCU or seqlock?

Well, the sighand->siglock is taken so many places in the kernel (>200 times)
that RCUing its usage looks like a daunting change to make.

In principle, I guess a seqlock could be made to work.  The idea would be that
we'd want to get a consistent copy of the sighand structure in the presence
of very rare updates.  Once again, I'd have to modify all of those code
paths mentioned above.

Since a seqlock was created AFAIK as an alternate to a brlock, and the
global/local locking structure I described before is more or less equivalent
to a brlock, I think we are thinking along similar lines.

For me, converting spinlock_irqsave(&p->sighand->siglock) to
spinlock_irqsave(&p->siglock) and then checking to make sure that
only task local data is updated in the critical section is an easier
way to go than modifying each of the code paths to deal with the
"failure" case for a seqlock.  But I could be proven wrong.

Anyway, Andi makes a good point -- if I can fast patch SIGPROF handling,
then I may have a more localized change, and that is a good thing [tm].

--
Best Regards,
Ray
-----------------------------------------------
                  Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@xxxxxxx             raybry@xxxxxxxxxxxxx
The box said: "Requires Windows 98 or better",
           so I installed Linux.
-----------------------------------------------
-
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/