Re: [PATCH 0/4] add task handling notifier

Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 25.12.07 23:05 >>>
On Sun, 23 Dec 2007 12:26:21 +0000 Christoph Hellwig <hch@xxxxxxxxxxxxx> 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.

Jan

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

Relevant Pages

  • Re: Bugs in kernels 2.6.20 plus 2.6.21 rc1 and 2
    ... Result: incompilable kernel! ... Reason is the following hunk: ... Would you please care for proper patch sets in future, ... unfortunately this only proves that all 2.6.20 changes modulo IDE ...
    (Linux-Kernel)
  • Re: PROBLEM: task->tty->driver problem/oops in proc_pid_sta
    ... >> main kernel yet. ... >> For unknown reason patch did not find its way to Linus's kernel yet, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [patch] let CONFIG_SECCOMP default to n
    ... I hope the reason was the lack of my last patch. ... users to switch distro if they don't want having to recompile the kernel ... You said yourself that your feature has currently exactly 121 users. ...
    (Linux-Kernel)
  • Re: [PATCH] x86/paravirt: revert exports to restore old behaviour
    ... Christoph Hellwig objects to this patch on the grounds that modules ... particularly good reason to reject the patch, ... CONFIG_PARAVIRT and non-CONFIG_PARAVIRT configurations. ... Current practice in the kernel is that when something that should not be ...
    (Linux-Kernel)
  • Re: [PATCH 0/4] add task handling notifier
    ... it seems reasonable to add notifiers that ... For some reason neither ever made a lot of progess (performance ... While I (obviously, since I submitted the patch disagree), ...
    (Linux-Kernel)