Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
pci-calgary.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.20.4/arch/x86_64/kernel/pci-cal
Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
pci-calgary.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.20.4/arch/x86_64/kernel/pci-calgary.c
Hello Andrew,
This patch fixes missing dependencies in drivers/connector/Kconfig
file. We have to ensure that the dependencies of the selected variable
are fulfilled otherwise it can produce some undefined references
during the kernel compilation. This problem was reported by Adrian Bunk.
Hello Andrew,
This patch fixes missing dependencies in drivers/connector/Kconfig
file. We have to ensure that the dependencies of the selected variable
are fulfilled otherwise it can produce some undefined references
during the kernel compilation. This problem was reported by Adrian Bunk.
Hello,
This patch removes the ugly union declaration in cn_fork.h and
cn_exit.h files. The code is cleaner without the union and the price is
only four bytes added in the structure.
Thanks to Alexander Nyberg for reporting this.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTEC
Hello,
This patch removes the ugly union declaration in cn_fork.h and
cn_exit.h files. The code is cleaner without the union and the price is
only four bytes added in the structure.
Thanks to Alexander Nyberg for reporting this.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED
Hello,
I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
seems that you removed the connector? Will you include it again in futur
release? At the same time, will you include the fork connector?
Thanks for your help,
Best regards,
Guillaume
-
To unsubscribe from this list:
Hello,
I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
seems that you removed the connector? Will you include it again in futur
release? At the same time, will you include the fork connector?
Thanks for your help,
Best regards,
Guillaume
-
To unsubscribe from this list:
On Tue, 2005-04-05 at 11:34 +0400, Evgeniy Polyakov wrote:
> On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote:
>
> >In fact to this day I still don't understand what problems this thing is
> >meant to solve.
>
> Hmm, what else can I add to my words?
> May be checking the size of the code
On Tue, 2005-04-05 at 11:34 +0400, Evgeniy Polyakov wrote:
On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote:
In fact to this day I still don't understand what problems this thing is
meant to solve.
Hmm, what else can I add to my words?
May be checking the size of the code needed to
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 113
g of the message) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume T
) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume Thouvenin [EMAIL
On Wed, 2005-03-30 at 20:25 +1000, Herbert Xu wrote:
> Paul Jackson <[EMAIL PROTECTED]> wrote:
> >
> > So I suppose if fork_connector were not used to collect > child pid> information for accounting, then someone would have to make
> > the case that there were enough other uses, of sufficient
On Wed, 2005-03-30 at 20:25 +1000, Herbert Xu wrote:
Paul Jackson [EMAIL PROTECTED] wrote:
So I suppose if fork_connector were not used to collect parent pid,
child pid information for accounting, then someone would have to make
the case that there were enough other uses, of sufficient
On Tue, 2005-03-29 at 22:06 -0800, dean gaudet wrote:
> On Tue, 29 Mar 2005, Jay Lan wrote:
>
> > The fork_connector is not designed to solve accounting data collection
> > problem.
> >
> > The accounting data collection must be done via a hook from do_exit().
>
> by the time do_exit() occurs
On Tue, 2005-03-29 at 07:35 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > I ran some test using the CBUS instead of the cn_netlink_send() routine
> > and the overhead is nearly 0%:
>
> Overhead of what? Does this include merging the data and getting it to
> disk?
I test the overhead of
On Tue, 2005-03-29 at 07:23 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The goal of the fork connector is to inform a user space application
> > that a fork occurs in the kernel. This information (cpu ID, parent PID
> > and child PID) can be used by several user space applications. It's
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The lmbench shows that the overhead (the construction and the sending
> > of the message) in the fork() routine is around 7%.
>
> Thanks for including the numbers. The 7% seems a bit costly, for a bit
> more
On Tue, 2005-03-29 at 00:49 -0800, Paul Jackson wrote:
> This
> amortizes the cost of almost all the handling, and of all the disk i/o,
> over many data collection events. Correct me if I'm wrong, but
> fork_connector doesn't do this merging of events into a consolidated
> data buffer, so is at
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The lmbench shows that the overhead (the construction and the sending
> > of the message) in the fork() routine is around 7%.
>
> Thanks for including the numbers. The 7% seems a bit costly, for a bit
> more
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
Guillaume wrote:
The lmbench shows that the overhead (the construction and the sending
of the message) in the fork() routine is around 7%.
Thanks for including the numbers. The 7% seems a bit costly, for a bit
more accounting
On Tue, 2005-03-29 at 00:49 -0800, Paul Jackson wrote:
This
amortizes the cost of almost all the handling, and of all the disk i/o,
over many data collection events. Correct me if I'm wrong, but
fork_connector doesn't do this merging of events into a consolidated
data buffer, so is at a
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
Guillaume wrote:
The lmbench shows that the overhead (the construction and the sending
of the message) in the fork() routine is around 7%.
Thanks for including the numbers. The 7% seems a bit costly, for a bit
more accounting
On Tue, 2005-03-29 at 07:23 -0800, Paul Jackson wrote:
Guillaume wrote:
The goal of the fork connector is to inform a user space application
that a fork occurs in the kernel. This information (cpu ID, parent PID
and child PID) can be used by several user space applications. It's not
On Tue, 2005-03-29 at 07:35 -0800, Paul Jackson wrote:
Guillaume wrote:
I ran some test using the CBUS instead of the cn_netlink_send() routine
and the overhead is nearly 0%:
Overhead of what? Does this include merging the data and getting it to
disk?
I test the overhead of sending the
On Tue, 2005-03-29 at 22:06 -0800, dean gaudet wrote:
On Tue, 29 Mar 2005, Jay Lan wrote:
The fork_connector is not designed to solve accounting data collection
problem.
The accounting data collection must be done via a hook from do_exit().
by the time do_exit() occurs the parent
needed
that fix problems in the connector.c file. At least, you need to apply
the patch provided in the second email.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_f
This patch fixes a bug in the __cn_rx_skb() routine when checking the
size of the netlink message.
It applies to 2.6.12-rc1-mm3.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
---
connector.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
Index:
Hello,
The following patch set adds a fork connector in the do_fork()
routine to 2.6.12-rc1-mm3 kernel.
We provide two patches. The first one is the fork connector
implementation and the second one fix a bug in the connector.c. The
second patch has been sent by Evgeniy Polyakov for
Hello,
The following patch set adds a fork connector in the do_fork()
routine to 2.6.12-rc1-mm3 kernel.
We provide two patches. The first one is the fork connector
implementation and the second one fix a bug in the connector.c. The
second patch has been sent by Evgeniy Polyakov for
This patch fixes a bug in the __cn_rx_skb() routine when checking the
size of the netlink message.
It applies to 2.6.12-rc1-mm3.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
---
connector.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
Index:
problems in the connector.c file. At least, you need to apply
the patch provided in the second email.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 104
On Tue, 2005-03-22 at 10:15 -0800, Jay Lan wrote:
> Guillaume Thouvenin wrote:
> > On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
> >
> >> If a bunch of applications are listening for fork events,
> >> your patch allows any application to turn off the
On Tue, 2005-03-22 at 10:15 -0800, Jay Lan wrote:
Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to turn off the
fork event notification
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
> If a bunch of applications are listening for fork events,
> your patch allows any application to turn off the
> fork event notification? Is this the right behavior?
Yes it is. The main management is done by application so, if
2003-01-30
11:24:37.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-16
14:34:41.0 +0100
@@ -0,0 +1,85 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program
On Thu, 2005-03-17 at 14:05 -0800, Jesse Barnes wrote:
> On Thursday, March 17, 2005 1:38 pm, Evgeniy Polyakov wrote:
> > The most significant part there - is requirement to store
> > u32 seq in each CPU's cache and thus flush cacheline +
> > invalidate/get from mem on each other cpus
> > each
On Thu, 2005-03-17 at 14:05 -0800, Jesse Barnes wrote:
On Thursday, March 17, 2005 1:38 pm, Evgeniy Polyakov wrote:
The most significant part there - is requirement to store
u32 seq in each CPU's cache and thus flush cacheline +
invalidate/get from mem on each other cpus
each time it is
:37.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-16
14:34:41.0 +0100
@@ -0,0 +1,85 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to turn off the
fork event notification? Is this the right behavior?
Yes it is. The main management is done by application so, if several
hat
fix problems in the connector.c file. At least, you need to apply the
patch provided in the second email.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/conn
Hello,
The following patch set adds a fork connector in the do_fork()
routine.
We provide two patches. The first one is the fork connector
implementation and the second one fix a bug in the connector.c. The
second patch has been sent by Evgeniy Polyakov for inclusion and should
be in the
This patch fixes a bug in the __cn_rx_skb() routine when checking the
size of the netlink message.
It applies to 2.6.11-mm4.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
---
connector.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
Index:
This patch fixes a bug in the __cn_rx_skb() routine when checking the
size of the netlink message.
It applies to 2.6.11-mm4.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
---
connector.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
Index:
Hello,
The following patch set adds a fork connector in the do_fork()
routine.
We provide two patches. The first one is the fork connector
implementation and the second one fix a bug in the connector.c. The
second patch has been sent by Evgeniy Polyakov for inclusion and should
be in the
in the connector.c file. At least, you need to apply the
patch provided in the second email.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
Hello,
In the ChangeLog-2.6.11 file I read that the enhanced I/O accounting
data patch and the enhanced memory accounting data collection patch were
added. It's cool but I don't see how this stuff is used because
information is never dump in a file or send to an accounting application
(or I
Hello,
In the ChangeLog-2.6.11 file I read that the enhanced I/O accounting
data patch and the enhanced memory accounting data collection patch were
added. It's cool but I don't see how this stuff is used because
information is never dump in a file or send to an accounting application
(or I
On Tue, 2005-03-08 at 08:29 +0100, Guillaume Thouvenin wrote:
> TODO:
> - Run the lmbench with the user space application that manages
> group of processus. if fork connector is not used the only
> overhead is a test in the do_fork() routine.
For information h
On Tue, 2005-03-08 at 08:29 +0100, Guillaume Thouvenin wrote:
TODO:
- Run the lmbench with the user space application that manages
group of processus. if fork connector is not used the only
overhead is a test in the do_fork() routine.
For information here are some results
the lmbench with the user space application that manages
group of processus. if fork connector is not used the only
overhead is a test in the do_fork() routine.
Thank you everyone for your comments,
Best regards,
Guillaume
Signed-off by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
I don't see the connector module [cn.ko] in this new release. Do you
remove it from your tree definitely?
Best regards,
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I don't see the connector module [cn.ko] in this new release. Do you
remove it from your tree definitely?
Best regards,
Guillaume
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
space application that manages
group of processus. if fork connector is not used the only
overhead is a test in the do_fork() routine.
Thank you everyone for your comments,
Best regards,
Guillaume
Signed-off by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig
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
> > an
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
This patch works with another
small patch that fix a problem in the connector. Without it, there is a
message that says "skb does not have enough length". It will be fix in
the next -mm tree I think.
Thanks everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouven
works with another
small patch that fix a problem in the connector. Without it, there is a
message that says skb does not have enough length. It will be fix in
the next -mm tree I think.
Thanks everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers
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 the
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 which
On Tue, 2005-03-01 at 10:06 -0800, Jay Lan wrote:
> Sorry I was not clear on my point.
>
> I was trying to point out that, an exit hook for BSD and CSA is
> essential to save accounting data before the data is gone. That
> can not be done with a netlink.
>
> So, my patch was to keep acct_process
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
ot see any profit here.
> Atomic allocation is fast, if it succeds, but there are no groups/socket to
> send,
> skb will be freed, if allocation fails, then group check is useless.
>
> I would prefer Guillaume Thouvenin as fork connector author to test
> his current implementation and show that conne
,
skb will be freed, if allocation fails, then group check is useless.
I would prefer Guillaume Thouvenin as fork connector author to test
his current implementation and show that connector's cost is negligible
both with and without userspace listeners.
As far as I remember it is first entry
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 the
On Tue, 2005-03-01 at 10:06 -0800, Jay Lan wrote:
Sorry I was not clear on my point.
I was trying to point out that, an exit hook for BSD and CSA is
essential to save accounting data before the data is gone. That
can not be done with a netlink.
So, my patch was to keep acct_process as a
On Mon, 2005-02-28 at 10:56 -0800, Jay Lan wrote:
> The exit hook is essential for CSA to save off data before the data
> is gone, A netlink type of thing does not help. BSD is in the same
> situation. You can not replace the acct_process() call with a netlink.
> If ELSA is to use the enhanced
On Mon, 2005-02-28 at 10:56 -0800, Jay Lan wrote:
The exit hook is essential for CSA to save off data before the data
is gone, A netlink type of thing does not help. BSD is in the same
situation. You can not replace the acct_process() call with a netlink.
If ELSA is to use the enhanced
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
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 netlink
On Thu, 2005-02-24 at 20:46 -0800, Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
> >
> > Since my idea of providing an accounting framework was considered
> > 'overkill', here i submit a tiny patch just to allow CSA to
> > handle end-of-process (eop) situation by saving off
On Thu, 2005-02-24 at 13:45 +0300, Evgeniy Polyakov wrote:
> >
> > Todo:
> >
> > - Test the performance impact with lmbench
> > - Improve the callback that turns on/off the fork connector
> > - Create a specific module to register the callback.
>
> Besides connector.c changes I do
Todo:
- Test the performance impact with lmbench
- Improve the callback that turns on/off the fork connector
- Create a specific module to register the callback.
Thanks to Andrew, Evgeniy and everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTE
with lmbench
- Improve the callback that turns on/off the fork connector
- Create a specific module to register the callback.
Thanks to Andrew, Evgeniy and everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
On Thu, 2005-02-24 at 13:45 +0300, Evgeniy Polyakov wrote:
Todo:
- Test the performance impact with lmbench
- Improve the callback that turns on/off the fork connector
- Create a specific module to register the callback.
Besides connector.c changes I do not have
On Thu, 2005-02-24 at 20:46 -0800, Andrew Morton wrote:
Jay Lan [EMAIL PROTECTED] wrote:
Since my idea of providing an accounting framework was considered
'overkill', here i submit a tiny patch just to allow CSA to
handle end-of-process (eop) situation by saving off accounting
data
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.
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > Please assume that > originally written for> will always be listening.
> >
> > > > What happened to the idea of sending an on/off message down the netlink
> > > > socket?
> > ...
> > Arrange for the userspace daemon to send a message
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
if defined(CONFIG_CONNECTOR)
- cn_netlink_send() sends messages to the correct group which is
CN_IDX_FORK
Thanks to Evgeniy and to everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig |8
include/linux/co
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 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 because of
)
- cn_netlink_send() sends messages to the correct group which is
CN_IDX_FORK
Thanks to Evgeniy and to everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig |8
include/linux/connector.h |2 ++
kernel
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 fork
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
Please assume that whatever secret application the connector stuff was
originally written for will always be listening.
What happened to the idea of sending an on/off message down the netlink
socket?
...
Arrange for the
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
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
>
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
depends
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a netlink interface. It allows to several
> > user space
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The problem is the following: I have a user space daemon that manages
> > group of processes. The main idea is, if a parent belongs to a group
> > then its child belongs to the same group. To achieve this I need to know
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> >
> > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
>
> I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
+#if defined(CONFIG_CONNECTOR) defined(CONFIG_FORK_CONNECTOR)
I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
Guillaume wrote:
The problem is the following: I have a user space daemon that manages
group of processes. The main idea is, if a parent belongs to a group
then its child belongs to the same group. To achieve this I need to know
when
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
It's a new patch that implements a fork connector in the
kernel/fork.c:do_fork() routine. The connector sends information about
parent PID and child PID over a netlink interface. It allows to several
user space applications to be
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent P
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
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 as BSD
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
It's a new patch that implements a fork connector in the
kernel/fork.c:do_fork() routine. The connector sends information about
parent PID and child PID over
1 - 100 of 130 matches
Mail list logo
