Andrew wrote:
> 5-10% slowdown on fork is expected, but
> why was exec slower?
Thanks for the summary, Andrew.
Guillaume (or anyone else tempted to do this) - it's a good idea, when
posting 100 lines of data, to summarize with a line or two of words, as
Andrew did here. It is far more efficient
On Wed, 2005-03-02 at 01:06 -0800, Andrew Morton wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > So I ran the lmbench with three different kernels with the fork
> > connector patch I just sent. Results are attached at the end of the mail
> > and there are three different lines
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> So I ran the lmbench with three different kernels with the fork
> connector patch I just sent. Results are attached at the end of the mail
> and there are three different lines which are:
>
> o First line is a linux-2.6.11-rc4-mm1-cnfor
On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote:
> > I tested without user space listeners and the cost is negligible. I will
> > test with a user space listeners and see the results. I'm going to run
> > the test this week after improving the mechanism that switch on/off the
> > sending of t
Just a thought - perhaps you could see if Jay can test the performance
scaling of these changes on larger systems (8 to 64 CPUs, give or take,
small for SGI, but big for some vendors.)
Things like a global lock, for example, might be harmless on smaller
systems, but hurt big time on bigger systems
Jamal wrote:
> What was wrong with just going ahead and just always
> invoking your netlink_send()?
I think the hope was to reduce the cost of the accounting hook in fork
to "next-to-zero" if accounting is not being used on that system.
See Andrew's query earlier:
> b) they are next-to-zero cost
On Tue, 2005-03-01 at 14:53 +0100, Guillaume Thouvenin wrote:
> On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote:
> > > I tested without user space listeners and the cost is negligible. I will
> > > test with a user space listeners and see the results. I'm going to run
> > > the test this week
On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote:
> > I tested without user space listeners and the cost is negligible. I will
> > test with a user space listeners and see the results. I'm going to run
> > the test this week after improving the mechanism that switch on/off the
> > sending of t
Hello,
> I tested without user space listeners and the cost is negligible. I will
> test with a user space listeners and see the results. I'm going to run
> the test this week after improving the mechanism that switch on/off the
> sending of the message.
I'm also trying to me
On Mon, 2005-02-28 at 19:17 +0300, Evgeniy Polyakov wrote:
> On 28 Feb 2005 10:31:33 -0500
> jamal <[EMAIL PROTECTED]> wrote:
> > I would bet the benefit you are seeing has to do with batching rather
> > than such an optimization flag. Different ballgame.
> > I relooked at their code snippet, they
On 28 Feb 2005 10:31:33 -0500
jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-28 at 09:25, Thomas Graf wrote:
> > * jamal <[EMAIL PROTECTED]> 2005-02-28 09:10
> [..]
> > > To justify writting the new code, I am assuming someone has actually sat
> > > down and in the minimal stuck their finger i
On Mon, 2005-02-28 at 09:25, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2005-02-28 09:10
[..]
> > To justify writting the new code, I am assuming someone has actually sat
> > down and in the minimal stuck their finger in the air
> > and said "yes, there is definetely wind there".
>
> I did,
* jamal <[EMAIL PROTECTED]> 2005-02-28 09:10
> On Mon, 2005-02-28 at 08:53, Thomas Graf wrote:
> > * jamal <[EMAIL PROTECTED]> 2005-02-28 08:40
> > >
> > > netlink broadcast or a wrapper around it.
> > > Why even bother doing the check with netlink_has_listeners()?
> >
> > To implement the master
On Mon, Feb 28, 2005 at 02:53:07PM +0100, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2005-02-28 08:40
> >
> > netlink broadcast or a wrapper around it.
> > Why even bother doing the check with netlink_has_listeners()?
>
> To implement the master enable/disable switch they want. The messages
On Mon, 2005-02-28 at 08:53, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2005-02-28 08:40
> >
> > netlink broadcast or a wrapper around it.
> > Why even bother doing the check with netlink_has_listeners()?
>
> To implement the master enable/disable switch they want. The messages
> don't get
* jamal <[EMAIL PROTECTED]> 2005-02-28 08:40
>
> netlink broadcast or a wrapper around it.
> Why even bother doing the check with netlink_has_listeners()?
To implement the master enable/disable switch they want. The messages
don't get send out anyway but why bother doing all the work if nothing
w
I'm net ignorant, so just hit me with a cluebat if thats appropriate.
On Mon, Feb 28, 2005 at 07:10:58AM -0500, jamal wrote:
>
> Havent seen the beginnings of this thread. But whatever you are trying
> to do seems to suggest some complexity that you are trying to
> workaround. What was wrong wit
netlink broadcast or a wrapper around it.
Why even bother doing the check with netlink_has_listeners()?
cheers,
jamal
On Mon, 2005-02-28 at 08:20, Thomas Graf wrote:
> > Havent seen the beginnings of this thread. But whatever you are trying
> > to do seems to suggest some complexity that you are
> Havent seen the beginnings of this thread. But whatever you are trying
> to do seems to suggest some complexity that you are trying to
> workaround. What was wrong with just going ahead and just always
> invoking your netlink_send()?
I guess parts of the wheel are broken and need to be reinvente
Havent seen the beginnings of this thread. But whatever you are trying
to do seems to suggest some complexity that you are trying to
workaround. What was wrong with just going ahead and just always
invoking your netlink_send()? If there are nobody in user space (or
kernel) listening, it wont go an
On Sun, 2005-02-27 at 23:39 -0800, Andrew Morton wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> >Ok the protocol is maybe too "basic" but with this mechanism the user
> > space application that uses the fork connector can start and stop the
> > send of messages. This implementa
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
>Ok the protocol is maybe too "basic" but with this mechanism the user
> space application that uses the fork connector can start and stop the
> send of messages. This implementation needs somme improvements because
> currently, if two applica
On Mon, 2005-02-28 at 10:59 +0900, Kaigai Kohei wrote:
> Marcelo Tosatti wrote:
> > Yep, the netlink people should be able to help - they known what would be
> > required for not sending messages in case there is no listener registered.
> >
> > Maybe its already possible? I have never used netl
On Mon, 2005-02-28 at 10:59 +0900, Kaigai Kohei wrote:
> Hello,
>
> Marcelo Tosatti wrote:
> > Yep, the netlink people should be able to help - they known what would be
> > required for not sending messages in case there is no listener registered.
> >
> > Maybe its already possible? I have nev
First of all, I'm not aware of the whole discussion, ignore this if it
has been brought to attention already.
> > Yep, the netlink people should be able to help - they known what would be
> > required for not sending messages in case there is no listener registered.
> >
> > Maybe its already possi
Hello,
Marcelo Tosatti wrote:
> Yep, the netlink people should be able to help - they known what would be
> required for not sending messages in case there is no listener registered.
>
> Maybe its already possible? I have never used netlink myself.
If we notify the fork/exec/exit-events to user-spa
On Sun, 27 Feb 2005 11:03:55 -0300
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> Yep, the netlink people should be able to help - they known what would be
> required for not sending messages in case there is no listener registered.
Please CC: netdev@oss.sgi.com to get some netlink discussions
goin
On Mon, Feb 28, 2005 at 12:20:40AM +0900, KaiGai Kohei wrote:
> Hi,
>
> >>Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> >>
> >>>In my understanding, what Andrew Morton said is "If target functionality
> >>>can
> >>>implement in user space only, then we should not modify the kernel-tree".
> >>
> >>for
Hi,
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality can
implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same common machinery a
On Thu, Feb 24, 2005 at 09:28:39PM -0800, Andrew Morton wrote:
> Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> >
> > In my understanding, what Andrew Morton said is "If target functionality can
> > implement in user space only, then we should not modify the kernel-tree".
>
> fork, exec and exit upcal
Andrew Morton wrote:
Jay Lan <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> Kaigai Kohei <[EMAIL PROTECTED]> wrote:
>
>>In my understanding, what Andrew Morton said is "If target functionality can
>> implement in user space only, then we should not modify the kernel-tree".
>
>
> fork, exec an
Jay Lan <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> >
> >>In my understanding, what Andrew Morton said is "If target functionality
> can
> >> implement in user space only, then we should not modify the kernel-tree".
> >
> >
> > fork,
Chris Wright wrote:
* Jay Lan ([EMAIL PROTECTED]) wrote:
Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality
can
implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls
* Jay Lan ([EMAIL PROTECTED]) wrote:
> Andrew Morton wrote:
> >Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> >
> >>In my understanding, what Andrew Morton said is "If target functionality
> >>can
> >>implement in user space only, then we should not modify the kernel-tree".
> >
> >
> >fork, exec and ex
Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality can
implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
>
> In my understanding, what Andrew Morton said is "If target functionality can
> implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same common machin
Sorry for this late reply.
>> [1] Is it necessary 'fork/exec/exit' event handling framework ?
..
>> Some process-aggregation model have own philosophy and implemantation,
>> so it's hard to integrate. Thus, I think that common 'fork/exec/exit'
>> event handling
>> framework to implement any
Tim Schmielau wrote:
On Tue, 22 Feb 2005, Andrew Morton 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
aggregatio
On Wed, 2005-02-23 at 11:11 -0800, Jay Lan wrote:
> Guillaume Thouvenin wrote:
> > 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
Jay wrote:
> I think the microbenchmarking your link provides is irrelevant.
In the cases such as you describe where it's just some sort of empty
function call, then yes, I am willing to accept a wave of the hands and
a simple explanation of how it's not significant. I've done the same
myself ;).
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be c
> So, I think such a fork/execve/exit hooks is harmless now.
I don't recall seeing any microbenchmarking of the impact on fork/exit
of such hooks. You might find such a benchmark in lmbench, or at
http://bulk.fefe.de/scalability/.
--
I won't rest till it's the best ...
Kaigai Kohei wrote:
Hi, Thanks for your comments.
>> I think there are two issues about system accounting framework.
>>
>> Issue: 1) How to define the appropriate unit for accounting ?
>> Current BSD-accountiong make a collection per process accounting
>> information.
>> CSA make additionally
Guillaume Thouvenin wrote:
On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
The common agreement for the method of dealing with process aggregation
has not been constructed yet, I understood. And, we will not able to
integrate each process aggregation
Hi, Thanks for your comments.
Andrew Morton wrote:
>> Some process-aggregation model have own philosophy and implemantation,
>> so it's hard to integrate. Thus, I think that common 'fork/exec/exit' event
handling
>> framework to implement any kinds of process-aggregation.
>
>
> We really want to a
On Tue, 22 Feb 2005, Andrew Morton 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
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> I will run benchmarks found at http://bulk.fefe.de/scalability/ to see
> how the fork connector impacts on the kernel.
The lmbench fork microbenchmark would suffice.
>All stuff that was previously done in kernel space and provided by the
>
On Wed, 2005-02-23 at 00:51 -0800, Andrew Morton wrote:
> > 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 fo
Guillaume Thouvenin <[EMAIL PROTECTED]> 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 per
On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote:
> Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> >
> > The common agreement for the method of dealing with process aggregation
> > has not been constructed yet, I understood. And, we will not able to
> > integrate each process aggregation model
On Tue, 2005-02-22 at 12:11 -0800, Jay Lan wrote:
> How ELSA adds per process accounting data
> to your grouping (banks) when a process exit? How do you save
> accounting data you need in task_struct before it is disposed? BSD
> handles that through acct_process() hook at do_exit(). CSA also
> dep
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
>
> The common agreement for the method of dealing with process aggregation
> has not been constructed yet, I understood. And, we will not able to
> integrate each process aggregation model because of its diverseness.
>
> For example, a process which bel
Hi, Thanks for your comments.
>> I think there are two issues about system accounting framework.
>>
>> Issue: 1) How to define the appropriate unit for accounting ?
>> Current BSD-accountiong make a collection per process accounting
>> information.
>> CSA make additionally a collection per process-
Kaigai Kohei wrote:
Hello, everyone.
Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
>
>>Since the need of Linux system accounting has gone beyond what BSD
>>accounting provides, i think it is a good idea to create a thin layer
>>of common code for various accounting packages, such a
Guillaume Thouvenin wrote:
On Fri, 2005-02-18 at 17:16 -0800, Andrew Morton wrote:
Jay Lan <[EMAIL PROTECTED]> wrote:
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various accounting packag
Hello, everyone.
Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
>
>>Since the need of Linux system accounting has gone beyond what BSD
>>accounting provides, i think it is a good idea to create a thin layer
>>of common code for various accounting packages, such as BSD accounting,
>>CSA,
On Fri, 2005-02-18 at 17:16 -0800, Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
> >
> > Since the need of Linux system accounting has gone beyond what BSD
> > accounting provides, i think it is a good idea to create a thin layer
> > of common code for various accounting packages, such
Jay Lan <[EMAIL PROTECTED]> wrote:
>
> Since the need of Linux system accounting has gone beyond what BSD
> accounting provides, i think it is a good idea to create a thin layer
> of common code for various accounting packages, such as BSD accounting,
> CSA, ELSA, etc. The hook to do_exit() at exit
It started with the need of CSA to handle end-of-process (eop) at
do_exit() at exit.c. The hook at exit.c was BSD Accounting specific.
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various
59 matches
Mail list logo
