Re: [Lse-tech] Re: A common layer for Accounting packages

From: Andrew Morton (akpm_at_osdl.org)
Date: 02/23/05

  • Next message: Francois Romieu: "Re: [rft/update] r8169 changes in 2.6.x" 
    Date:	Wed, 23 Feb 2005 00:51:35 -0800
To: Guillaume Thouvenin <guillaume.thouvenin@bull.net>

    Guillaume Thouvenin <guillaume.thouvenin@bull.net> wrote:
    >
    > ...
    >
    > > We really want to avoid doing such stuff in-kernel if at all possible, of
    > > course.
    > >
    > > Is it not possible to implement the fork/exec/exit notifications to
    > > userspace so that a daemon can track the process relationships and perform
    > > aggregation based upon individual tasks' accounting? That's what one of
    > > the accounting systems is proposing doing, I believe.
    >
    > It's what I'm proposing. The problem is to be alerted when a new process
    > is created in order to add it in the correct group of processes if the
    > parent belongs to one (or several) groups. The notification can be done
    > with the fork connector patch.

    Yes, it sounds sane.

    The 2.6.8.1 ELSA patch adds quite a bit of kernel code, but from what
    you're saying it seems like most of that has become redundant, and all
    you now need is the fork notifier. Is that correct?

    That 2.6.8.1 ELSA patch looks reasonable to me - it only adds two lines to
    generic code and the rest looks pretty straightforward. Are we sure that
    this level of functionality is not sufficient for everyone else?

    > > (In fact, why do we even need the notifications? /bin/ps can work this
    > > stuff out).
    >
    > Yes it can but the risk is to lose some forks no?
    > I think that /bin/ps is using the /proc interface. If we're polling
    > the /proc to catch process creation we may lost some of them. With the
    > fork connector we catch all forks and we can check that by using the
    > sequence number (incremented by each fork) of the message.

    Oh, I wasn't proposing that it all be done via existing /proc interfaces -
    I was just getting my head straight ;)

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

  • Next message: Francois Romieu: "Re: [rft/update] r8169 changes in 2.6.x"

    Relevant Pages

    • Re: silent semantic changes with reiser4
      ... >> He's not proposing to add it to 2.4, ... So run it in -mm or fork it to 2.7. ... send the line "unsubscribe linux-kernel" in ... Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: mremap() bug IMHO not in 2.2
      ... > Just guessing, but would a zero-length vma be rounded up to a page, and ... vma's (fork() and exit()) simply knows that a vma can never be ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3
      ... > multithreaded OpenMP STREAM running its childs first on the same node ... i believe the fix we want is to pre-balance the context at fork() time. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: deferred rss update instead of sloppy rss
      ... Linus Torvalds wrote: ... >>The problem is then that the proc filesystem must do an extensive scan ... Then, at fork, you just finish the forkwith ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: process creation time increases linearly with shmem
      ... some apps may not want hugetlb pages to be all ... That's why I was alluding towards having the user specify MAP_SHARED| ... MAP_LAZY or something to that tune and then have fork() honor it. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)