Date:	Tue, 08 Jan 2008 18:47:00 -0800
From:	Matt Helsley <matthltc@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jan Beulich <jbeulich@...ell.com>, hch@...radead.org,
	pagg@....sgi.com, erikj@....com, pj@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] add task handling notifier

On Tue, 2008-01-08 at 14:14 -0800, Andrew Morton wrote:
> On Tue, 08 Jan 2008 13:38:03 +0000
> "Jan Beulich" <jbeulich@...ell.com> wrote:
> 
> > >>> Andrew Morton <akpm@...ux-foundation.org> 25.12.07 23:05 >>>
> > >On Sun, 23 Dec 2007 12:26:21 +0000 Christoph Hellwig <hch@...radead.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists