From: Andrew Morton <akpm@linux-foundation.org>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Jan Beulich <jbeulich@novell.com>,
hch@infradead.org, pagg@oss.sgi.com, erikj@sgi.com, pj@sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] add task handling notifier
Date: Tue, 8 Jan 2008 19:22:07 -0800 [thread overview]
Message-ID: <20080108192207.4646e574.akpm@linux-foundation.org> (raw)
In-Reply-To: <1199846820.17010.166.camel@localhost.localdomain>
On Tue, 08 Jan 2008 18:47:00 -0800 Matt Helsley <matthltc@us.ibm.com> wrote:
> > >
> ...
> > > 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?
How does that work? module.c does the register/deregister on behalf of the
module?
I certainly encourage people to disagreee with me here, but my current
thinking is:
- the cleanup aspect isn't worth the runtime overhead and
- the support-modular-users aspect is largely new and would need a lot
more description and justification (with examples) before we can even
begin to evaluate it.
next prev parent reply other threads:[~2008-01-09 3:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 13:11 [PATCH 0/4] add task handling notifier Jan Beulich
2007-12-20 22:25 ` Ingo Oeser
2007-12-21 7:36 ` Jan Beulich
2007-12-23 12:26 ` Christoph Hellwig
2007-12-25 22:05 ` Andrew Morton
2008-01-08 13:38 ` Jan Beulich
2008-01-08 22:14 ` Andrew Morton
2008-01-09 0:03 ` Paul Jackson
2008-01-09 0:31 ` Andrew Morton
2008-01-09 2:47 ` Matt Helsley
2008-01-09 3:22 ` Andrew Morton [this message]
2008-01-09 9:52 ` Jan Beulich
2008-01-09 10:03 ` Christoph Hellwig
2008-01-09 2:24 ` Matt Helsley
2008-01-09 3:27 ` Matthew Helsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080108192207.4646e574.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=erikj@sgi.com \
--cc=hch@infradead.org \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=pagg@oss.sgi.com \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.