On Tue, 08 Jan 2008 13:38:03 +0000 "Jan Beulich" <[EMAIL PROTECTED]> wrote:
> >>> Andrew Morton <[EMAIL PROTECTED]> 25.12.07 23:05 >>> > >On Sun, 23 Dec 2007 12:26:21 +0000 Christoph Hellwig <[EMAIL PROTECTED]> > >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. The requirement which I thought we were addressing was "clean the code up by adding a notifier chain so multiple subsystems don't need to patch in hard-coded calls". My contention is that the code clarity which this gains isn't worth the runtime cost. Now we have a new requirement: "allow out-of-tree code to hook into these spots without needing to patch those few callsites". I think we'd need a pretty detailed description of the pain which this would relieve before we would take such an extraordinary step. What are those (unidentified) add-on features doing at present? Patching calls into fork.c/exec.c/exit.c? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/