From: Jes S. <je...@sg...> - 2006-05-08 08:31:16
|
Alan Stern wrote: > On Fri, 5 May 2006, Jes Sorensen wrote: >> The patches were meant more to show the idea, I didn't claim they were >> final production quality<tm>. But you're right, doing it in the raw >> chain would make more sense. > > All right then. How do you feel about combining a global raw_notifier > chain (for drivers interested in all tasks) that is protected by a > "no-cache-bounce-for-readers" rw-semaphore together with a per-task > raw_notifier chain that is protected by nothing (accessed only from within > the task's context)? How do you anticipate that no-cache-bounce-for-readers? Whenever a reader takes a semaphore they still have to go and update the semaphore, when the next reader comes in on a different CPU that reader still has to pull over the cacheline to update it. This is why I keep pointing out that rw locks are no better when it comes to cache impact! > You'd have to write an API for registering and > unregistering on each type of chain, including dynamic allocation of the > notifier_blocks, plus an API for invoking the chains (easy) and one for > destroying the per-task chains (called only from do_exit or one of its > subordinates). I'd go back to Jack's original patch for this, shouldn't be too big a deal. >> It happens to be applicable to this application, but I don't see why >> it wouldn't work for other cases, hence placing it in kernel/sys.c > > My feeling for now is keep it separate, since it's just a part of your > private API. If other parts of the kernel want to use it then it can be > moved later. It would never be part of any private API, it would be for 'public' use, EXPORT_SYMBOL_GPL naturally. > The "no-cache-bounce" rw-sem, on the other hand, is a candidate for > mainlining. We could see what Andrew Morton and others think about it. I am very curious how you expect to achieve this .... Jes |