Messages in this thread | | | Subject | Re: [PATCH 0/4] add task handling notifier | From | Matt Helsley <> | Date | Tue, 08 Jan 2008 18:47:00 -0800 |
| |
On Tue, 2008-01-08 at 14:14 -0800, Andrew Morton wrote: > On Tue, 08 Jan 2008 13:38:03 +0000 > "Jan Beulich" <jbeulich@novell.com> wrote: > > > >>> Andrew Morton <akpm@linux-foundation.org> 25.12.07 23:05 >>> > > >On Sun, 23 Dec 2007 12:26:21 +0000 Christoph Hellwig <hch@infradead.org> wrote: > > > > > >> On Thu, Dec 20, 2007 at 01:11:24PM +0000, Jan Beulich wrote: > > >> > With more and more sub-systems/sub-components leaving their footprint > > >> > in task handling functions, it seems reasonable to add notifiers that > > >> > these components can use instead of having them all patch themselves > > >> > directly into core files. > > >> > > >> I agree that we probably want something like this. As do some others, > > >> so we already had a few a few attempts at similar things. The first one > > >> is from SGI and called PAGG (http://oss.sgi.com/projects/pagg/) and also > > >> includes allocating per-task data for it's users. Then also from SGI > > >> there has been a simplified version called pnotify that's also available > > >> from the website above. > > >> > > >> Later Matt Helsley had something called "Task Watchers" which lwn has > > >> an article on: http://lwn.net/Articles/208117/. > > >> > > >> For some reason neither ever made a lot of progess (performance > > >> problems?). > > >> > > > > > >I had it in -mm, sorted out all the problems but ended up not pulling the > > >trigger. > > > > > >Problem is, it adds runtime overhead purely for the convenience of kernel > > >programmers, and I don't think that's a good tradeoff. > > > > > >Sprinkling direct calls into a few well-known sites won't kill us, and > > >we've survived this long. Why not keep doing that, and save everyone a few > > >cycles? > > > > Am I to conclude then that there's no point in addressing the issues other > > people pointed out? While I (obviously, since I submitted the patch disagree), > > I'm not certain how others feel. My main point for disagreement here is (I'm > > sorry to repeat this) that as long as certain code isn't allowed into the kernel > > I think it is not unreasonable to at least expect the kernel to provide some > > fundamental infrastructure that can be used for those (supposedly > > unacceptable) bits. All I did here was utilizing the base infrastructure I want > > added to clean up code that appeared pretty ad-hoc. > > > > Ah. That's a brand new requirement.
In all fairness it's not really a brand new requirement -- just one that wasn't strongly emphasized during prior attempts to get something like this in.
I had a mostly-working patch for this on top of the Task Watchers v2 patch set. I never posted that specific patch because it had a race with module unloading and the fix only increased the overhead you were unhappy with. I mentioned it briefly in my lengthy [PATCH 0/X] description for Task Watchers v2 (http://lwn.net/Articles/207873/):
"TODO: ... I'm working on three more patches that add support for creating a task watcher from within a module using an ELF section. They haven't recieved as much attention since I've been focusing on measuring the performance impact of these patches."
<snip>
Would tainting the kernel upon registration of out-of-tree "notifiers" be more acceptable?
Cheers, -Matt Helsley
| |