From: Ray B. <ra...@sg...> - 2004-11-22 19:48:57
|
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) ra...@sg... ra...@au... The box said: "Requires Windows 98 or better", so I installed Linux. ----------------------------------------------- |