[PATCH 2.6.20.4] pci-calgary: cleanup of unneeded macros
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 === --- linux-2.6.20.4.orig/arch/x86_64/kernel/pci-calgary.c2007-04-06 09:42:12.0 +0200 +++ linux-2.6.20.4/arch/x86_64/kernel/pci-calgary.c 2007-04-06 09:42:20.0 +0200 @@ -53,11 +53,6 @@ #define PCI_VENDOR_DEVICE_ID_CALGARY \ (PCI_VENDOR_ID_IBM | PCI_DEVICE_ID_IBM_CALGARY << 16) -/* we need these for register space address calculation */ -#define START_ADDRESS 0xfe00 -#define CHASSIS_BASE0 -#define ONE_BASED_CHASSIS_NUM 1 - /* register offsets inside the host bridge space */ #define CALGARY_CONFIG_REG 0x0108 #define PHB_CSR_OFFSET 0x0110 /* Channel Status */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20.4] pci-calgary: cleanup of unneeded macros
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 === --- linux-2.6.20.4.orig/arch/x86_64/kernel/pci-calgary.c2007-04-06 09:42:12.0 +0200 +++ linux-2.6.20.4/arch/x86_64/kernel/pci-calgary.c 2007-04-06 09:42:20.0 +0200 @@ -53,11 +53,6 @@ #define PCI_VENDOR_DEVICE_ID_CALGARY \ (PCI_VENDOR_ID_IBM | PCI_DEVICE_ID_IBM_CALGARY 16) -/* we need these for register space address calculation */ -#define START_ADDRESS 0xfe00 -#define CHASSIS_BASE0 -#define ONE_BASED_CHASSIS_NUM 1 - /* register offsets inside the host bridge space */ #define CALGARY_CONFIG_REG 0x0108 #define PHB_CSR_OFFSET 0x0110 /* Channel Status */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] connector: fix missing dependencies in Kconfig
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. Signed-off-by: [EMAIL PROTECTED] Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Index: linux-2.6.13-rc3-mm1/drivers/connector/Kconfig === --- linux-2.6.13-rc3-mm1.orig/drivers/connector/Kconfig 2005-07-18 13:35:26.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/connector/Kconfig 2005-07-18 13:37:43.0 +0200 @@ -12,6 +12,7 @@ config CONNECTOR config EXIT_CONNECTOR bool "Enable exit connector" + depends on NET select CONNECTOR default y ---help--- @@ -23,6 +24,7 @@ config EXIT_CONNECTOR config FORK_CONNECTOR bool "Enable fork connector" + depends on NET select CONNECTOR default y ---help--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3-mm1] connector: fix missing dependencies in Kconfig
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. Signed-off-by: [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- Index: linux-2.6.13-rc3-mm1/drivers/connector/Kconfig === --- linux-2.6.13-rc3-mm1.orig/drivers/connector/Kconfig 2005-07-18 13:35:26.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/connector/Kconfig 2005-07-18 13:37:43.0 +0200 @@ -12,6 +12,7 @@ config CONNECTOR config EXIT_CONNECTOR bool Enable exit connector + depends on NET select CONNECTOR default y ---help--- @@ -23,6 +24,7 @@ config EXIT_CONNECTOR config FORK_CONNECTOR bool Enable fork connector + depends on NET select CONNECTOR default y ---help--- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc1-mm1] connector: Remove the union declaration
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]>
---
drivers/connector/cn_exit.c |8
drivers/connector/cn_fork.c | 10 +-
include/linux/cn_exit.h | 16
include/linux/cn_fork.h | 18 +-
4 files changed, 26 insertions(+), 26 deletions(-)
Index: linux-2.6.13-rc1-mm1/drivers/connector/cn_exit.c
===
--- linux-2.6.13-rc1-mm1.orig/drivers/connector/cn_exit.c 2005-07-04
14:20:59.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/connector/cn_exit.c2005-07-04
14:36:47.0 +0200
@@ -73,9 +73,9 @@ void exit_connector(pid_t pid, pid_t pti
exitmsg = (struct cn_exit_msg *)msg->data;
exitmsg->type = EXIT_CN_MSG_P;
exitmsg->cpu = smp_processor_id();
- exitmsg->u.s.pid = pid;
- exitmsg->u.s.ptid = ptid;
- exitmsg->u.s.code = code;
+ exitmsg->pid = pid;
+ exitmsg->ptid = ptid;
+ exitmsg->code = code;
put_cpu_var(exit_counts);
@@ -107,7 +107,7 @@ static inline void cn_exit_send_status(v
msg->len = CN_EXIT_INFO_SIZE;
exitmsg = (struct cn_exit_msg *)msg->data;
exitmsg->type = EXIT_CN_MSG_S;
- exitmsg->u.status = cn_exit_enable;
+ exitmsg->status = cn_exit_enable;
cn_netlink_send(msg, CN_IDX_EXIT, GFP_KERNEL);
}
Index: linux-2.6.13-rc1-mm1/drivers/connector/cn_fork.c
===
--- linux-2.6.13-rc1-mm1.orig/drivers/connector/cn_fork.c 2005-07-04
14:20:59.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/connector/cn_fork.c2005-07-04
14:36:50.0 +0200
@@ -72,10 +72,10 @@ void fork_connector(pid_t ppid, pid_t pt
forkmsg = (struct cn_fork_msg *)msg->data;
forkmsg->type = FORK_CN_MSG_P;
forkmsg->cpu = smp_processor_id();
- forkmsg->u.s.ppid = ppid;
- forkmsg->u.s.ptid = ptid;
- forkmsg->u.s.cpid = cpid;
- forkmsg->u.s.ctid = ctid;
+ forkmsg->ppid = ppid;
+ forkmsg->ptid = ptid;
+ forkmsg->cpid = cpid;
+ forkmsg->ctid = ctid;
put_cpu_var(fork_counts);
@@ -107,7 +107,7 @@ static inline void cn_fork_send_status(v
msg->len = CN_FORK_INFO_SIZE;
forkmsg = (struct cn_fork_msg *)msg->data;
forkmsg->type = FORK_CN_MSG_S;
- forkmsg->u.status = cn_fork_enable;
+ forkmsg->status = cn_fork_enable;
cn_netlink_send(msg, CN_IDX_FORK, GFP_KERNEL);
}
Index: linux-2.6.13-rc1-mm1/include/linux/cn_exit.h
===
--- linux-2.6.13-rc1-mm1.orig/include/linux/cn_exit.h 2005-07-04
14:21:05.0 +0200
+++ linux-2.6.13-rc1-mm1/include/linux/cn_exit.h2005-07-04
14:42:11.0 +0200
@@ -41,14 +41,14 @@ struct cn_exit_msg {
int type; /* 0: information about processes
1: exit connector's state */
int cpu;/* ID of the cpu where the exit occurred */
- union {
- struct {
- pid_t pid; /* process ID */
- pid_t ptid; /* process thread ID */
- pid_t code; /* process exit code */
- } s;
- int status;
- } u;
+
+ /* Information about processes */
+ pid_t pid; /* process ID */
+ pid_t ptid; /* process thread ID */
+ pid_t code; /* process exit code */
+
+ /* Exit connector's state */
+ int status;
};
/* Code above is only inside the kernel */
Index: linux-2.6.13-rc1-mm1/include/linux/cn_fork.h
===
--- linux-2.6.13-rc1-mm1.orig/include/linux/cn_fork.h 2005-07-04
14:21:05.0 +0200
+++ linux-2.6.13-rc1-mm1/include/linux/cn_fork.h2005-07-04
14:39:17.0 +0200
@@ -49,15 +49,15 @@ struct cn_fork_msg {
int type; /* 0: information about processes
1: fork connector's state */
int cpu;/* ID of the cpu where the fork occurred */
- union {
- struct {
- pid_t ppid; /* parent process ID */
- pid_t ptid; /* parent thread ID */
- pid_t cpid; /* child process ID */
- pid_t ctid; /* child thread ID
[PATCH 2.6.13-rc1-mm1] connector: Remove the union declaration
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]
---
drivers/connector/cn_exit.c |8
drivers/connector/cn_fork.c | 10 +-
include/linux/cn_exit.h | 16
include/linux/cn_fork.h | 18 +-
4 files changed, 26 insertions(+), 26 deletions(-)
Index: linux-2.6.13-rc1-mm1/drivers/connector/cn_exit.c
===
--- linux-2.6.13-rc1-mm1.orig/drivers/connector/cn_exit.c 2005-07-04
14:20:59.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/connector/cn_exit.c2005-07-04
14:36:47.0 +0200
@@ -73,9 +73,9 @@ void exit_connector(pid_t pid, pid_t pti
exitmsg = (struct cn_exit_msg *)msg-data;
exitmsg-type = EXIT_CN_MSG_P;
exitmsg-cpu = smp_processor_id();
- exitmsg-u.s.pid = pid;
- exitmsg-u.s.ptid = ptid;
- exitmsg-u.s.code = code;
+ exitmsg-pid = pid;
+ exitmsg-ptid = ptid;
+ exitmsg-code = code;
put_cpu_var(exit_counts);
@@ -107,7 +107,7 @@ static inline void cn_exit_send_status(v
msg-len = CN_EXIT_INFO_SIZE;
exitmsg = (struct cn_exit_msg *)msg-data;
exitmsg-type = EXIT_CN_MSG_S;
- exitmsg-u.status = cn_exit_enable;
+ exitmsg-status = cn_exit_enable;
cn_netlink_send(msg, CN_IDX_EXIT, GFP_KERNEL);
}
Index: linux-2.6.13-rc1-mm1/drivers/connector/cn_fork.c
===
--- linux-2.6.13-rc1-mm1.orig/drivers/connector/cn_fork.c 2005-07-04
14:20:59.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/connector/cn_fork.c2005-07-04
14:36:50.0 +0200
@@ -72,10 +72,10 @@ void fork_connector(pid_t ppid, pid_t pt
forkmsg = (struct cn_fork_msg *)msg-data;
forkmsg-type = FORK_CN_MSG_P;
forkmsg-cpu = smp_processor_id();
- forkmsg-u.s.ppid = ppid;
- forkmsg-u.s.ptid = ptid;
- forkmsg-u.s.cpid = cpid;
- forkmsg-u.s.ctid = ctid;
+ forkmsg-ppid = ppid;
+ forkmsg-ptid = ptid;
+ forkmsg-cpid = cpid;
+ forkmsg-ctid = ctid;
put_cpu_var(fork_counts);
@@ -107,7 +107,7 @@ static inline void cn_fork_send_status(v
msg-len = CN_FORK_INFO_SIZE;
forkmsg = (struct cn_fork_msg *)msg-data;
forkmsg-type = FORK_CN_MSG_S;
- forkmsg-u.status = cn_fork_enable;
+ forkmsg-status = cn_fork_enable;
cn_netlink_send(msg, CN_IDX_FORK, GFP_KERNEL);
}
Index: linux-2.6.13-rc1-mm1/include/linux/cn_exit.h
===
--- linux-2.6.13-rc1-mm1.orig/include/linux/cn_exit.h 2005-07-04
14:21:05.0 +0200
+++ linux-2.6.13-rc1-mm1/include/linux/cn_exit.h2005-07-04
14:42:11.0 +0200
@@ -41,14 +41,14 @@ struct cn_exit_msg {
int type; /* 0: information about processes
1: exit connector's state */
int cpu;/* ID of the cpu where the exit occurred */
- union {
- struct {
- pid_t pid; /* process ID */
- pid_t ptid; /* process thread ID */
- pid_t code; /* process exit code */
- } s;
- int status;
- } u;
+
+ /* Information about processes */
+ pid_t pid; /* process ID */
+ pid_t ptid; /* process thread ID */
+ pid_t code; /* process exit code */
+
+ /* Exit connector's state */
+ int status;
};
/* Code above is only inside the kernel */
Index: linux-2.6.13-rc1-mm1/include/linux/cn_fork.h
===
--- linux-2.6.13-rc1-mm1.orig/include/linux/cn_fork.h 2005-07-04
14:21:05.0 +0200
+++ linux-2.6.13-rc1-mm1/include/linux/cn_fork.h2005-07-04
14:39:17.0 +0200
@@ -49,15 +49,15 @@ struct cn_fork_msg {
int type; /* 0: information about processes
1: fork connector's state */
int cpu;/* ID of the cpu where the fork occurred */
- union {
- struct {
- pid_t ppid; /* parent process ID */
- pid_t ptid; /* parent thread ID */
- pid_t cpid; /* child process ID */
- pid_t ctid; /* child thread ID */
- } s;
- int status;
- } u;
+
+ /* Information about processes */
+ pid_t ppid
connector is missing in 2.6.12-rc2-mm1
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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
connector is missing in 2.6.12-rc2-mm1
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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink Connector / CBUS
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 broadcast kobject changes > in kobject_uevent.c for example... > Netlink socket allocation + skb handling against call to cn_netlink_send(). And It's the same for the fork connector. It allows to send a message to a user space application when a fork occurs by adding only one line (two with the #include) in the kernel/fork.c file. Thus, the netlink connector is a very simple and fast mechanism when you need to send a small amount of information from kernel space to user space. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink Connector / CBUS
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 broadcast kobject changes in kobject_uevent.c for example... Netlink socket allocation + skb handling against call to cn_netlink_send(). And It's the same for the fork connector. It allows to send a message to a user space application when a fork occurs by adding only one line (two with the #include) in the kernel/fork.c file. Thus, the netlink connector is a very simple and fast mechanism when you need to send a small amount of information from kernel space to user space. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
ChangeLog:
- Remove unnecessary catch in cn_fork_callback().
- Use reverse dependencies in Kconfig. By doing this, if fork
connector is enabled, the connector will be automatically
selected as built-in. It's the what we need.
- Move the cn_fork_enable and cb_fork_id declarations inside
CONFIG_FORK_CONNECTOR.
- Use DECLARE_PER_CPU in connector.h and DEFINE_PER_CPU in fork.c
to avoid fork_counts to be defined in each compilation unit which
includes include/linux/connector.h
- Add a description of the fork connector in the beginning of the
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
include/linux/connector.h | 54 +
kernel/fork.c | 11
5 files changed, 190 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-04-01
08:02:25.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ select CONNECTOR
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-04-01
12:48:47.0 +0200
@@ -0,0 +1,113 @@
+/*
+ * cn_fork.c - Fork connector
+ *
+ * Copyright (C) 2005 Guillaume Thouvenin <[EMAIL PROTECTED]>
+ *
+ * This module implements the fork connector. It allows to send a
+ * netlink datagram, when enabled, from the do_fork() routine. The
+ * message can be read by a user space application. By this way,
+ * the user space application is alerted when a fork occurs.
+ *
+ * It uses the userspace <-> kernelspace connector that works on top of
+ * the netlink protocol. The fork connector is enabled or disabled by
+ * sending a message to the connector. The unique sequence number of
+ * messages can be used to check if a message is lost.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO: An informational line in log is maybe not enough... */
+ printk(KERN_INFO "cn_fork_enable == %d\n", cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
ChangeLog:
- Remove unnecessary catch in cn_fork_callback().
- Use reverse dependencies in Kconfig. By doing this, if fork
connector is enabled, the connector will be automatically
selected as built-in. It's the what we need.
- Move the cn_fork_enable and cb_fork_id declarations inside
CONFIG_FORK_CONNECTOR.
- Use DECLARE_PER_CPU in connector.h and DEFINE_PER_CPU in fork.c
to avoid fork_counts to be defined in each compilation unit which
includes include/linux/connector.h
- Add a description of the fork connector in the beginning of the
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
include/linux/connector.h | 54 +
kernel/fork.c | 11
5 files changed, 190 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-04-01
08:02:25.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ select CONNECTOR
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-04-01
12:48:47.0 +0200
@@ -0,0 +1,113 @@
+/*
+ * cn_fork.c - Fork connector
+ *
+ * Copyright (C) 2005 Guillaume Thouvenin [EMAIL PROTECTED]
+ *
+ * This module implements the fork connector. It allows to send a
+ * netlink datagram, when enabled, from the do_fork() routine. The
+ * message can be read by a user space application. By this way,
+ * the user space application is alerted when a fork occurs.
+ *
+ * It uses the userspace - kernelspace connector that works on top of
+ * the netlink protocol. The fork connector is enabled or disabled by
+ * sending a message to the connector. The unique sequence number of
+ * messages can be used to check if a message is lost.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO: An informational line in log is maybe not enough... */
+ printk(KERN_INFO cn_fork_enable == %d\n, cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
[patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace <-> kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost. In this patch we use
a cn_fork_msg structure (thanks to Dean Gaudet) rather than zeroing 64
bytes of memory and doing conversions to decimal ascii as done before.
Also we move the fork_connector() inline code in the header file
include/linux/connector.h as suggested by Paul Jackson (thanks).
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
When the fork connector is disabled, the "lat_proc fork" test returns
a value equal to:
Process fork+exit: 150.2076 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 153.7778 microseconds
So the overhead (the construction and the sending 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 Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 104
include/linux/connector.h | 53 ++
kernel/fork.c |3 +
5 files changed, 172 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-03-31
14:57:52.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-31
14:57:52.0 +0200
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO "cn_fork_enable == %d\n
[patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace - kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost. In this patch we use
a cn_fork_msg structure (thanks to Dean Gaudet) rather than zeroing 64
bytes of memory and doing conversions to decimal ascii as done before.
Also we move the fork_connector() inline code in the header file
include/linux/connector.h as suggested by Paul Jackson (thanks).
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
When the fork connector is disabled, the lat_proc fork test returns
a value equal to:
Process fork+exit: 150.2076 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 153.7778 microseconds
So the overhead (the construction and the sending 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 Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 104
include/linux/connector.h | 53 ++
kernel/fork.c |3 +
5 files changed, 172 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-03-31
14:57:52.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-31
14:57:52.0 +0200
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO cn_fork_enable == %d\n, cn_fork_enable
Re: [patch 1/2] fork_connector: add a fork connector
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 value, to add > > fork_connector. We have to be a bit careful, in the kernel, to avoid > > adding mechanisms until we have the immediate use in hand. If we don't > > do this, then the kernel ends up looking like the Gargoyles on a > > Renaissance church - burdened with overly ornate features serving no > > earthly purpose. > > I agree completely. In fact the whole drivers/connector directory > looks pretty suspect. Are there any in-kernel users of it at all? There is the Enhanced Linux System Accounting project http://elsa.sourceforge.net 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 value, to add fork_connector. We have to be a bit careful, in the kernel, to avoid adding mechanisms until we have the immediate use in hand. If we don't do this, then the kernel ends up looking like the Gargoyles on a Renaissance church - burdened with overly ornate features serving no earthly purpose. I agree completely. In fact the whole drivers/connector directory looks pretty suspect. Are there any in-kernel users of it at all? There is the Enhanced Linux System Accounting project http://elsa.sourceforge.net 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 may have disappeared... you do > need to record something at fork() time so that you can account to the > correct ancestor. You're right. At fork(), the "job daemon", provided by ELSA, records information about parent PID, child PID and also about the group of processes they belong to. At exit(), accounting data are recorded by CSA or BSD-like accounting. > an example of where this ancestry is useful would be the summation of all > cpu time spent by children of apache, spamd, clamd, ... You're right. One usage can be: apache, spamd and clamd can be put in a job (a group of processes) by using the "job daemon" and automatically, all children will belong to the same jobs respectively. So the gaol here is really to perform per-group of processes accounting using ELSA and CSA accounting data. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 fork information to a user space application. The merge of the data is done later and it has nothing to do with the fork connector... > Am I even asking the right question here - is it true that this data, > when collected for accounting purposes, needs to go to disk, and that > summarizing and analyzing the data is done 'off-line', perhaps hours > later? That's the way it was 25 years ago ... but perhaps the basic > data flow appropriate for accounting has changed since then. Accounting is another problem and, as you said previously, summarizing and analyzing the data is done later. I'm sorry but I really don't understand why you're speaking about accounting when I present results about fork connector. I agree that ELSA is using the fork connector but the fork connector has nothing to do with accounting. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 > > only for accounting. Accounting and fork_connector are two different > > things and thus, fork_connector doesn't do the merge of any kinds of > > data (and it will never do). > > Yes - it is clear that the fork_connector does this - inform user space > of fork information . I'm not saying that > fork_connector should merge data; I'm observing that it doesn't, and > that this would seem to serve the needs of accounting poorly. > > Out of curiosity, what are these 'several user space applications?' The > only one I know of is this extension to bsd accounting to include > capturing parent and child pid at fork. Probably you've mentioned some > other uses of fork_connector before here, but I missed it. During the discussion some people like Erich Focht and Ram mentioned that this information can be useful for them. I remember that Erich had in mind something like cluster-wide pid tracking in user space. When I wrote "several user space applications" it was just to say that this fork connector is not designed only for ELSA and fork information is available to every listeners. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 information. Perhaps dean's suggestion, to not use > ascii, will help. I hope so, though I doubt it will make a huge > difference. Was this 7% loss with or without a user level program > consuming the sent messages? I would think that the number of interest > would include a minimal consumer task. I ran some test using the CBUS instead of the cn_netlink_send() routine and the overhead is nearly 0%: fork connector disabled: Process fork+exit: 148.1429 microseconds fork connector enabled: Process fork+exit: 148.4595 microseconds 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 distinct disadvantage, for this use, because the > data merging is delayed, and a separate, user level process, is required > to accomplish the merging and conversion to writable blocks of data > suitable for storing on the disk. 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 only for accounting. Accounting and fork_connector are two different things and thus, fork_connector doesn't do the merge of any kinds of data (and it will never do). One difference with relayfs is the amount of datas that are transfered. The relayfs is done, like Evgeniy said, for large amount of datas. So I think that it's not suitable for what we want to achieve with the fork connector. I hope this help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 information. Perhaps dean's suggestion, to not use > ascii, will help. I hope so, though I doubt it will make a huge > difference. Was this 7% loss with or without a user level program > consuming the sent messages? I would think that the number of interest > would include a minimal consumer task. Yes, dean's suggestion helps. The overhead is now around 4% fork_connector disabled: Process fork+exit: 149. microseconds fork_connector enabled: Process fork+exit: 154.9167 microseconds > Having the "#ifdef CONFIG_FORK_CONNECTOR" chunk of code right in fork.c > seems unfortunate. Can the real fork_connector() be put elsewhere, and > the ifdef put in a header file that makes it a no-op if not configured, > or simply a function declaration, if configured? I think that it can be moved in include/linux/connector.h 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 information. Perhaps dean's suggestion, to not use ascii, will help. I hope so, though I doubt it will make a huge difference. Was this 7% loss with or without a user level program consuming the sent messages? I would think that the number of interest would include a minimal consumer task. Yes, dean's suggestion helps. The overhead is now around 4% fork_connector disabled: Process fork+exit: 149. microseconds fork_connector enabled: Process fork+exit: 154.9167 microseconds Having the #ifdef CONFIG_FORK_CONNECTOR chunk of code right in fork.c seems unfortunate. Can the real fork_connector() be put elsewhere, and the ifdef put in a header file that makes it a no-op if not configured, or simply a function declaration, if configured? I think that it can be moved in include/linux/connector.h 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 distinct disadvantage, for this use, because the data merging is delayed, and a separate, user level process, is required to accomplish the merging and conversion to writable blocks of data suitable for storing on the disk. 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 only for accounting. Accounting and fork_connector are two different things and thus, fork_connector doesn't do the merge of any kinds of data (and it will never do). One difference with relayfs is the amount of datas that are transfered. The relayfs is done, like Evgeniy said, for large amount of datas. So I think that it's not suitable for what we want to achieve with the fork connector. I hope this help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 information. Perhaps dean's suggestion, to not use ascii, will help. I hope so, though I doubt it will make a huge difference. Was this 7% loss with or without a user level program consuming the sent messages? I would think that the number of interest would include a minimal consumer task. I ran some test using the CBUS instead of the cn_netlink_send() routine and the overhead is nearly 0%: fork connector disabled: Process fork+exit: 148.1429 microseconds fork connector enabled: Process fork+exit: 148.4595 microseconds 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 only for accounting. Accounting and fork_connector are two different things and thus, fork_connector doesn't do the merge of any kinds of data (and it will never do). Yes - it is clear that the fork_connector does this - inform user space of fork information cpu, parent, child. I'm not saying that fork_connector should merge data; I'm observing that it doesn't, and that this would seem to serve the needs of accounting poorly. Out of curiosity, what are these 'several user space applications?' The only one I know of is this extension to bsd accounting to include capturing parent and child pid at fork. Probably you've mentioned some other uses of fork_connector before here, but I missed it. During the discussion some people like Erich Focht and Ram mentioned that this information can be useful for them. I remember that Erich had in mind something like cluster-wide pid tracking in user space. When I wrote several user space applications it was just to say that this fork connector is not designed only for ELSA and fork information is available to every listeners. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 fork information to a user space application. The merge of the data is done later and it has nothing to do with the fork connector... Am I even asking the right question here - is it true that this data, when collected for accounting purposes, needs to go to disk, and that summarizing and analyzing the data is done 'off-line', perhaps hours later? That's the way it was 25 years ago ... but perhaps the basic data flow appropriate for accounting has changed since then. Accounting is another problem and, as you said previously, summarizing and analyzing the data is done later. I'm sorry but I really don't understand why you're speaking about accounting when I present results about fork connector. I agree that ELSA is using the fork connector but the fork connector has nothing to do with accounting. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 may have disappeared... you do need to record something at fork() time so that you can account to the correct ancestor. You're right. At fork(), the job daemon, provided by ELSA, records information about parent PID, child PID and also about the group of processes they belong to. At exit(), accounting data are recorded by CSA or BSD-like accounting. an example of where this ancestry is useful would be the summation of all cpu time spent by children of apache, spamd, clamd, ... You're right. One usage can be: apache, spamd and clamd can be put in a job (a group of processes) by using the job daemon and automatically, all children will belong to the same jobs respectively. So the gaol here is really to perform per-group of processes accounting using ELSA and CSA accounting data. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace <-> kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. This operation should be done by
only one application. Such application can be downloaded from
http://cvs.sourceforge.net/viewcvs.py/elsa/elsa_project/utils/fcctl.c
The unique sequence number of messages can be used to check if a
message is lost. This sequence number is relative to a CPU.
The lmbench shows that the overhead (the construction and the sending
of the message) in the fork() routine is around 7%.
This patch applies to 2.6.12-rc1-mm3. Some other patches are 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_fork.c | 104
include/linux/connector.h |8 +++
kernel/fork.c | 44 ++
5 files changed, 168 insertions(+)
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/Kconfig 2005-03-25
09:47:09.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Kconfig 2005-03-25
10:14:21.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/Makefile 2005-03-25
09:47:09.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Makefile 2005-03-25
10:14:21.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/cn_fork.c 2005-03-25
10:14:21.0 +0100
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO "cn_fork_enable == %d\n", cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_c
[patch 2/2] fork_connector: fix problem in the message lenght
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: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/connector.c
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/connector.c
2005-03-25 10:42:57.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/connector.c 2005-03-25
10:43:16.0 +0100
@@ -168,12 +168,11 @@ static int __cn_rx_skb(struct sk_buff *s
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) {
printk(KERN_ERR "skb does not have enough length: "
- "requested msg->len=%u[%u],
nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n",
- msg->len, NLMSG_SPACE(msg->len),
- nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh),
- skb->len, msg->len + sizeof(*msg));
+ "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
+ msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
+ nlh->nlmsg_len, skb->len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] fork_connector
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 inclusion and should be in the next -mm release. While it's not included, we provide it with the fork connector to allow people to use and test the fork connector. Those patches apply to 2.6.12-rc1-mm3. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] fork_connector
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 inclusion and should be in the next -mm release. While it's not included, we provide it with the fork connector to allow people to use and test the fork connector. Those patches apply to 2.6.12-rc1-mm3. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] fork_connector: fix problem in the message lenght
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: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/connector.c
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/connector.c
2005-03-25 10:42:57.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/connector.c 2005-03-25
10:43:16.0 +0100
@@ -168,12 +168,11 @@ static int __cn_rx_skb(struct sk_buff *s
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg-len != nlh-nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg-len + sizeof(*msg)) != nlh-nlmsg_len) {
printk(KERN_ERR skb does not have enough length:
- requested msg-len=%u[%u],
nlh-nlmsg_len=%u[%u], skb-len=%u[must be %u].\n,
- msg-len, NLMSG_SPACE(msg-len),
- nlh-nlmsg_len, nlh-nlmsg_len - sizeof(*nlh),
- skb-len, msg-len + sizeof(*msg));
+ requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
+ msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
+ nlh-nlmsg_len, skb-len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace - kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. This operation should be done by
only one application. Such application can be downloaded from
http://cvs.sourceforge.net/viewcvs.py/elsa/elsa_project/utils/fcctl.c
The unique sequence number of messages can be used to check if a
message is lost. This sequence number is relative to a CPU.
The lmbench shows that the overhead (the construction and the sending
of the message) in the fork() routine is around 7%.
This patch applies to 2.6.12-rc1-mm3. Some other patches are 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_fork.c | 104
include/linux/connector.h |8 +++
kernel/fork.c | 44 ++
5 files changed, 168 insertions(+)
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/Kconfig 2005-03-25
09:47:09.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Kconfig 2005-03-25
10:14:21.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/Makefile 2005-03-25
09:47:09.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/Makefile 2005-03-25
10:14:21.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm3-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm3-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm3-cnfork/drivers/connector/cn_fork.c 2005-03-25
10:14:21.0 +0100
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO cn_fork_enable == %d\n, cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg
Re: [patch 1/2] fork_connector: add a fork connector
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? Is this the right behavior?
> >
> >
> > Yes it is. The main management is done by application so, if several
> > applications are listening for fork events you need to choose which one
> > will turn off the fork connector.
>
> It is not practical. One listener never know who else are listening
> to the fork connector.
>
> We also need to protect yet another global variable "cn_fork_enable".
>
> Also, in order to implement "cn_fork_enable" as a counter, we need
> some sort of registration to prevent an application from sending
> repeated "off" notification. One can only turn off its own switch.
I agree with the Evgeniy's ip example. I can provide a fork connector
interface utility to enable or disable the fork connector. Thus,
listeners don't have to start and stop the fork connector and they don't
have to worry about who else are listening the fork connector. It also
removes the need of registration.
I copy at the end of this email the code of the fork connector
controller application (called fcctl).
I need to add the possibility to get the state of the fork connector.
I also need to extend the fork connector to send to everyone information
when it is turned off/on.
Regards,
Guillaume
/*
* fcctl.c - Fork connector interface utility
*
* Used to turn on/off the fork connector
*/
#include
#include
#include
#include
#include
#include
#include
#define MESSAGE_SIZE(sizeof(struct nlmsghdr) + \
sizeof(struct cn_msg) + \
sizeof(int))
#define FORK_CN_DISABLE 0
#define FORK_CN_ENABLE 1
#define FORK_CN_UNKNOWN 2
void show_help()
{
printf("usage: fcctl {on|off}\n\n");
}
int main(int argc, char **argv)
{
int sk_nl;
int err;
int action = FORK_CN_UNKNOWN;
struct sockaddr_nl sa_nl; /* info for the netlink interface */
char buff[128]; /* must be > MESSAGE_SIZE */
struct nlmsghdr *hdr;
struct cn_msg *mesg;
if (getuid() != 0) {
printf("Only root can start/stop the fork connector\n");
return 0;
}
if (argc != 2) {
show_help();
return 0;
}
if (strcmp(argv[1], "on") == 0)
action = FORK_CN_ENABLE;
else if (strcmp(argv[1], "off") == 0)
action = FORK_CN_DISABLE;
if (action == FORK_CN_UNKNOWN) {
show_help();
return 0;
}
/*
* Create an endpoint for communication. Use the kernel user
* interface device (PF_NETLINK) which is a datagram oriented
* service (SOCK_DGRAM). The protocol used is the netfilter/iptables
* ULOG protocol (NETLINK_NFLOG)
*/
sk_nl = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_NFLOG);
if (sk_nl == -1) {
printf("socket sk_nl error");
return -1;
}
sa_nl.nl_family = AF_NETLINK;
sa_nl.nl_groups = CN_IDX_FORK;
sa_nl.nl_pid = getpid();
err = bind(sk_nl, (struct sockaddr *)_nl, sizeof(sa_nl));
if (err == -1) {
printf("binding sk_nl error");
close(sk_nl);
return -1;
}
/* Clear the buffer */
memset(buff, '\0', sizeof(buff));
/* fill the message header */
hdr = (struct nlmsghdr *)buff;
hdr->nlmsg_len = MESSAGE_SIZE;
hdr->nlmsg_type = NLMSG_DONE;
hdr->nlmsg_flags = 0;
hdr->nlmsg_seq = 0;
hdr->nlmsg_pid = getpid();
/* the message */
mesg = (struct cn_msg *)NLMSG_DATA(hdr);
mesg->id.idx = CN_IDX_FORK;
mesg->id.val = CN_VAL_FORK;
mesg->seq = 0;
mesg->ack = 0;
mesg->len = sizeof(int);
mesg->data[0] = action;
send(sk_nl, hdr, hdr->nlmsg_len, 0);
close(sk_nl);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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? Is this the right behavior?
Yes it is. The main management is done by application so, if several
applications are listening for fork events you need to choose which one
will turn off the fork connector.
It is not practical. One listener never know who else are listening
to the fork connector.
We also need to protect yet another global variable cn_fork_enable.
Also, in order to implement cn_fork_enable as a counter, we need
some sort of registration to prevent an application from sending
repeated off notification. One can only turn off its own switch.
I agree with the Evgeniy's ip example. I can provide a fork connector
interface utility to enable or disable the fork connector. Thus,
listeners don't have to start and stop the fork connector and they don't
have to worry about who else are listening the fork connector. It also
removes the need of registration.
I copy at the end of this email the code of the fork connector
controller application (called fcctl).
I need to add the possibility to get the state of the fork connector.
I also need to extend the fork connector to send to everyone information
when it is turned off/on.
Regards,
Guillaume
/*
* fcctl.c - Fork connector interface utility
*
* Used to turn on/off the fork connector
*/
#include stdio.h
#include string.h
#include unistd.h
#include sys/socket.h
#include sys/types.h
#include linux/connector.h
#include linux/netlink.h
#define MESSAGE_SIZE(sizeof(struct nlmsghdr) + \
sizeof(struct cn_msg) + \
sizeof(int))
#define FORK_CN_DISABLE 0
#define FORK_CN_ENABLE 1
#define FORK_CN_UNKNOWN 2
void show_help()
{
printf(usage: fcctl {on|off}\n\n);
}
int main(int argc, char **argv)
{
int sk_nl;
int err;
int action = FORK_CN_UNKNOWN;
struct sockaddr_nl sa_nl; /* info for the netlink interface */
char buff[128]; /* must be MESSAGE_SIZE */
struct nlmsghdr *hdr;
struct cn_msg *mesg;
if (getuid() != 0) {
printf(Only root can start/stop the fork connector\n);
return 0;
}
if (argc != 2) {
show_help();
return 0;
}
if (strcmp(argv[1], on) == 0)
action = FORK_CN_ENABLE;
else if (strcmp(argv[1], off) == 0)
action = FORK_CN_DISABLE;
if (action == FORK_CN_UNKNOWN) {
show_help();
return 0;
}
/*
* Create an endpoint for communication. Use the kernel user
* interface device (PF_NETLINK) which is a datagram oriented
* service (SOCK_DGRAM). The protocol used is the netfilter/iptables
* ULOG protocol (NETLINK_NFLOG)
*/
sk_nl = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_NFLOG);
if (sk_nl == -1) {
printf(socket sk_nl error);
return -1;
}
sa_nl.nl_family = AF_NETLINK;
sa_nl.nl_groups = CN_IDX_FORK;
sa_nl.nl_pid = getpid();
err = bind(sk_nl, (struct sockaddr *)sa_nl, sizeof(sa_nl));
if (err == -1) {
printf(binding sk_nl error);
close(sk_nl);
return -1;
}
/* Clear the buffer */
memset(buff, '\0', sizeof(buff));
/* fill the message header */
hdr = (struct nlmsghdr *)buff;
hdr-nlmsg_len = MESSAGE_SIZE;
hdr-nlmsg_type = NLMSG_DONE;
hdr-nlmsg_flags = 0;
hdr-nlmsg_seq = 0;
hdr-nlmsg_pid = getpid();
/* the message */
mesg = (struct cn_msg *)NLMSG_DATA(hdr);
mesg-id.idx = CN_IDX_FORK;
mesg-id.val = CN_VAL_FORK;
mesg-seq = 0;
mesg-ack = 0;
mesg-len = sizeof(int);
mesg-data[0] = action;
send(sk_nl, hdr, hdr-nlmsg_len, 0);
close(sk_nl);
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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
applications are listening for fork events you need to choose which one
will turn off the fork connector.
I want to keep this turn on/off mechanism simple but if it's needed I
can manage the variable "cn_fork_enable" as a counter. Thus the callback
could be something like:
static void cn_fork_callback(void *data)
{
int start;
struct cn_msg *msg = (struct cn_msg *)data;
if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) {
memcpy(, msg->data, sizeof(cn_fork_enable));
if (start)
cn_fork_enable++;
else
cn_fork_enable > 0 ? cn_fork_enable-- : 0;
}
}
What do you think about this implementation?
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
ChangeLog:
- Remove the global cn_fork_lock and replace it by a per CPU
counter.
- The processor ID has been added in the data part of the message.
Thus datas sent in a message are: "CPU_ID PARENT_PID CHILD_PID"
Those modifications were done to be more scalable because, as
mentioned by Jesse Barnes, the global cn_fork_lock won't work well on a
large CPU system.
This patch applies to 2.6.11-mm4.
Regards,
Guillaume
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig 2005-03-16
14:34:41.0 +0100
@@ -10,4 +10,15 @@
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Makefile 2005-03-16
14:34:41.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/cn_fork.c2003-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 is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable)))
+ memcpy(_fork_enable, msg->data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(_fork_id, "cn_fork", _fork_callback);
+ if (err) {
+ printk(KERN_WARNING "Failed to register cn_fork\n");
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE "cn_fork is registered\n");
+ re
Re: [patch 1/2] fork_connector: add a fork connector
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 accessed, which is a big price. > > Same thing has to happen with the lock. To put it simply, writing global > variables from multiple CPUs with anything other than very low frequency is > bad. > > > It is totally Guillaume's work - so he decides, > > I would recomend per cpu counters and processor's > > id in each message. > > And of course userspace should take care of misordered > > messages. > > I personally prefer such mechanism. > > Yep, I agree. Hopefully Guillaume will too :) Sure, I agree and I will implement the per cpu counters solution with a processor id in each message. Thank you very much Jesse and Evgeniy for your great help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
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 accessed, which is a big price. Same thing has to happen with the lock. To put it simply, writing global variables from multiple CPUs with anything other than very low frequency is bad. It is totally Guillaume's work - so he decides, I would recomend per cpu counters and processor's id in each message. And of course userspace should take care of misordered messages. I personally prefer such mechanism. Yep, I agree. Hopefully Guillaume will too :) Sure, I agree and I will implement the per cpu counters solution with a processor id in each message. Thank you very much Jesse and Evgeniy for your great help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
ChangeLog:
- Remove the global cn_fork_lock and replace it by a per CPU
counter.
- The processor ID has been added in the data part of the message.
Thus datas sent in a message are: CPU_ID PARENT_PID CHILD_PID
Those modifications were done to be more scalable because, as
mentioned by Jesse Barnes, the global cn_fork_lock won't work well on a
large CPU system.
This patch applies to 2.6.11-mm4.
Regards,
Guillaume
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig 2005-03-16
14:34:41.0 +0100
@@ -10,4 +10,15 @@
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Makefile 2005-03-16
14:34:41.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/cn_fork.c2003-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 is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized (msg-len == sizeof(cn_fork_enable)))
+ memcpy(cn_fork_enable, msg-data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(cb_fork_id, cn_fork, cn_fork_callback);
+ if (err) {
+ printk(KERN_WARNING Failed to register cn_fork\n);
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE cn_fork is registered\n);
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
Re: [patch 1/2] fork_connector: add a fork connector
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
applications are listening for fork events you need to choose which one
will turn off the fork connector.
I want to keep this turn on/off mechanism simple but if it's needed I
can manage the variable cn_fork_enable as a counter. Thus the callback
could be something like:
static void cn_fork_callback(void *data)
{
int start;
struct cn_msg *msg = (struct cn_msg *)data;
if (cn_already_initialized (msg-len == sizeof(cn_fork_enable))) {
memcpy(start, msg-data, sizeof(cn_fork_enable));
if (start)
cn_fork_enable++;
else
cn_fork_enable 0 ? cn_fork_enable-- : 0;
}
}
What do you think about this implementation?
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace <-> kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost.
When the fork connector is disabled, the "lat_proc fork" test returns
a value equal to:
Process fork+exit: 154.6944 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 165.6667 microseconds
So the overhead (the construction and the sending of the message) is
around 7%.
This patch applies to 2.6.11-mm4. Some other patches are 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_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig 2005-03-16
14:34:41.0 +0100
@@ -10,4 +10,15 @@
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Makefile 2005-03-16
14:34:41.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/cn_fork.c2003-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 is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable)))
+ memcpy(_fork_enable, msg-&g
[patch 0/2] fork_connector
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 next -mm release. While it's not included, we provide it with the fork connector to allow people to use and test the fork connector. Those patches apply to 2.6.11-mm4. I may not answer the questions before next Monday, sorry for the delay. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] fork_connector: fix problem in the message lenght
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: linux-2.6.11-mm4-cnfork/drivers/connector/connector.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/connector.c 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/connector.c 2005-03-16
14:51:04.0 +0100
@@ -168,12 +168,11 @@
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) {
printk(KERN_ERR "skb does not have enough length: "
- "requested msg->len=%u[%u],
nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n",
- msg->len, NLMSG_SPACE(msg->len),
- nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh),
- skb->len, msg->len + sizeof(*msg));
+ "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
+ msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
+ nlh->nlmsg_len, skb->len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] fork_connector: fix problem in the message lenght
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: linux-2.6.11-mm4-cnfork/drivers/connector/connector.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/connector.c 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/connector.c 2005-03-16
14:51:04.0 +0100
@@ -168,12 +168,11 @@
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg-len != nlh-nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg-len + sizeof(*msg)) != nlh-nlmsg_len) {
printk(KERN_ERR skb does not have enough length:
- requested msg-len=%u[%u],
nlh-nlmsg_len=%u[%u], skb-len=%u[must be %u].\n,
- msg-len, NLMSG_SPACE(msg-len),
- nlh-nlmsg_len, nlh-nlmsg_len - sizeof(*nlh),
- skb-len, msg-len + sizeof(*msg));
+ requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
+ msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
+ nlh-nlmsg_len, skb-len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] fork_connector
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 next -mm release. While it's not included, we provide it with the fork connector to allow people to use and test the fork connector. Those patches apply to 2.6.11-mm4. I may not answer the questions before next Monday, sorry for the delay. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace - kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost.
When the fork connector is disabled, the lat_proc fork test returns
a value equal to:
Process fork+exit: 154.6944 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 165.6667 microseconds
So the overhead (the construction and the sending of the message) is
around 7%.
This patch applies to 2.6.11-mm4. Some other patches are 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_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Kconfig 2005-03-16
14:34:41.0 +0100
@@ -10,4 +10,15 @@
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.11-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-16
14:21:46.0 +0100
+++ linux-2.6.11-mm4-cnfork/drivers/connector/Makefile 2005-03-16
14:34:41.0 +0100
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.11-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.11-mm4-cnfork.orig/drivers/connector/cn_fork.c2003-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 is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized (msg-len == sizeof(cn_fork_enable)))
+ memcpy(cn_fork_enable, msg-data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init
I/O and Memory accounting...
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 miss something). Maybe we should update the ac_io in the "struct acct"? Thus, values will be dump in the accounting file. Maybe it could be something like: --- acct.c.orig 2005-03-09 14:17:07.0 +0100 +++ acct.c 2005-03-09 14:18:20.0 +0100 @@ -477,8 +477,8 @@ static void do_acct_process(long exitcod } vsize = vsize / 1024; ac.ac_mem = encode_comp_t(vsize); - ac.ac_io = encode_comp_t(0 /* current->io_usage */);/* %% */ - ac.ac_rw = encode_comp_t(ac.ac_io / 1024); + ac.ac_io = encode_comp_t(current->rchar + current->wchar); + ac.ac_rw = encode_comp_t(0); ac.ac_minflt = encode_comp_t(current->signal->min_flt + current->group_leader->min_flt); ac.ac_majflt = encode_comp_t(current->signal->maj_flt + For memory and read/write syscall we may add new fields. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I/O and Memory accounting...
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 miss something). Maybe we should update the ac_io in the struct acct? Thus, values will be dump in the accounting file. Maybe it could be something like: --- acct.c.orig 2005-03-09 14:17:07.0 +0100 +++ acct.c 2005-03-09 14:18:20.0 +0100 @@ -477,8 +477,8 @@ static void do_acct_process(long exitcod } vsize = vsize / 1024; ac.ac_mem = encode_comp_t(vsize); - ac.ac_io = encode_comp_t(0 /* current-io_usage */);/* %% */ - ac.ac_rw = encode_comp_t(ac.ac_io / 1024); + ac.ac_io = encode_comp_t(current-rchar + current-wchar); + ac.ac_rw = encode_comp_t(0); ac.ac_minflt = encode_comp_t(current-signal-min_flt + current-group_leader-min_flt); ac.ac_majflt = encode_comp_t(current-signal-maj_flt + For memory and read/write syscall we may add new fields. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
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 when using the process creation tests "lat_proc fork". Test was run ten times thus the average is computed with the ten metrics. with a kernel 2.6.11-rc4-mm1 max value = 164.0588 msec min value = 159.8571 msec average = 161.7012 msec with a kernel 2.6.11-rc4-mm1 and the cnfork (cn_fork_enable == 0) max value = 163.3438 msec min value = 159.8857 msec average = 160.9447 msec with a kernel 2.6.11-rc4-mm1 and the cnfork (cn_fork_enable == 1) max value = 177.6885 msec min value = 170.9057 msec average = 173.7675 msec So we see that when the fork connector is disable the time it takes to split a process into two copies is the same (and it's normal) and when the fork connector is enable, it's around 7.5% slower. Best, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
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 when using the process creation tests lat_proc fork. Test was run ten times thus the average is computed with the ten metrics. with a kernel 2.6.11-rc4-mm1 max value = 164.0588 msec min value = 159.8571 msec average = 161.7012 msec with a kernel 2.6.11-rc4-mm1 and the cnfork (cn_fork_enable == 0) max value = 163.3438 msec min value = 159.8857 msec average = 160.9447 msec with a kernel 2.6.11-rc4-mm1 and the cnfork (cn_fork_enable == 1) max value = 177.6885 msec min value = 170.9057 msec average = 173.7675 msec So we see that when the fork connector is disable the time it takes to split a process into two copies is the same (and it's normal) and when the fork connector is enable, it's around 7.5% slower. Best, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
Hello,
This patch cannot be apply on a 2.6.11-mm1 because connector is
missing in this release. The connector module should be back in the next
kernel release. That's why it applies on a 2.6.11-rc4-mm1 tree.
Also, there is a problem with the drivers/connector/connector.c file.
The test
if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh))
must be replaced by
if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len)
Without this change, there is a problem with the size of messages. It
should be fix in future version of the connector module.
ChangeLog:
- Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
in the CN_FORK_MSG_SIZE macro
- fork_cn_lock is declared with DEFINE_SPINLOCK()
- fork_cn_lock is defined as static and local to fork_connector()
- Create a specific module cn_fork.c in drivers/connector to
register the callback
- Improve the callback that turns on/off the fork connector. Now
to enable the fork connector you need to send a message with
the length of the data equal to sizeof(int) and data is '1' to
enable (or '0' to disable).
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.
Thank you everyone for your comments,
Best regards,
Guillaume
Signed-off by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c
--- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01
13:13:05.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 it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable)))
+ memcpy(_fork_enable, msg->data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(_fork_id, "cn_fork", _fork_callback);
+ if (err) {
+ printk(KERN_WARNING "Failed to register cn_fork\n");
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE "cn_fork is registered\n");
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
+ *
+ * As this driver is always statically compiled into the kernel the
+ * cn_fork_exit has no effect.
+ */
+static void cn_fork_exit(void)
+{
+ cn_del_callback(_fork_id);
+}
+
+module_init(cn_fork_init);
+module_exit(cn_fork_exit);
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfi
Re: 2.6.11-mm1
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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm1
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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
Hello,
This patch cannot be apply on a 2.6.11-mm1 because connector is
missing in this release. The connector module should be back in the next
kernel release. That's why it applies on a 2.6.11-rc4-mm1 tree.
Also, there is a problem with the drivers/connector/connector.c file.
The test
if (msg-len != nlh-nlmsg_len - sizeof(*msg) - sizeof(*nlh))
must be replaced by
if (NLMSG_SPACE(msg-len + sizeof(*msg)) != nlh-nlmsg_len)
Without this change, there is a problem with the size of messages. It
should be fix in future version of the connector module.
ChangeLog:
- Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
in the CN_FORK_MSG_SIZE macro
- fork_cn_lock is declared with DEFINE_SPINLOCK()
- fork_cn_lock is defined as static and local to fork_connector()
- Create a specific module cn_fork.c in drivers/connector to
register the callback
- Improve the callback that turns on/off the fork connector. Now
to enable the fork connector you need to send a message with
the length of the data equal to sizeof(int) and data is '1' to
enable (or '0' to disable).
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.
Thank you everyone for your comments,
Best regards,
Guillaume
Signed-off by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c
--- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01
13:13:05.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 it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized (msg-len == sizeof(cn_fork_enable)))
+ memcpy(cn_fork_enable, msg-data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(cb_fork_id, cn_fork, cn_fork_callback);
+ if (err) {
+ printk(KERN_WARNING Failed to register cn_fork\n);
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE cn_fork is registered\n);
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
+ *
+ * As this driver is always statically compiled into the kernel the
+ * cn_fork_exit has no effect.
+ */
+static void cn_fork_exit(void)
+{
+ cn_del_callback(cb_fork_id);
+}
+
+module_init(cn_fork_init);
+module_exit(cn_fork_exit);
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02
Re: [Lse-tech] Re: A common layer for Accounting packages
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 are:
> >
> > o First line is a linux-2.6.11-rc4-mm1-cnfork
> > o Second line is a linux-2.6.11-rc4-mm1
> > o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space
> >application. The user space application listened during 15h
> >and received 6496 messages.
> >
> > Each test has been ran only once.
> >
> > ...
> >
> > --
> > Host OS Mhz null null open slct sig sig fork exec
> > sh
> > call I/O stat clos TCP inst hndl proc proc
> > proc
> > - -
> >
> > account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629.
> > 2415
> > account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628.
> > 2417
> > account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664.
> > 2456
>
> This is the interesting bit, yes? 5-10% slowdown on fork is expected, but
> why was exec slower?
I can't explain it for the moment. I will run test more than once to see
if this difference is still here.
> What does "The user space application listened during 15h" mean?
It means that I ran the user space application before the test and
stop it 15 hours later (this morning for me). The test ran during
5h30mn.
The user space application increments a counter to show how many
processes have been created during a period of time. I have not use the
user space daemon that manages group of processes because the it still
uses the old mechanism (a signal sends from the do_fork()) and as I
wanted to provide quick results, I used another user space application.
I attache the test program (get_fork_info.c) that I'm using at the end
of the mail to clearly show what it does.
I will run new tests with the real user space daemon but it will be
ready next week, sorry for the delay.
Best regards,
Guillaume
---
/*
* get_fork_info.c
*
* This program listens netlink interface to retreive information
* sends by the kernel when forking. It increments a counter for
* each forks and when the user hit CRL-C, it displays how many
* fork occured during the period.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define CN_FORK_OFF 0
#define CN_FORK_ON 1
#define MESSAGE_SIZE(sizeof(struct nlmsghdr) + \
sizeof(struct cn_msg) + \
sizeof(int))
int sock;
unsigned long total_p;
struct timeval test_time;
static inline void switch_cn_fork(int sock, int action)
{
char buff[128]; /* must be > MESSAGE_SIZE */
struct nlmsghdr *hdr;
struct cn_msg *msg;
/* Clear the buffer */
memset(buff, '\0', sizeof(buff));
/* fill the message header */
hdr = (struct nlmsghdr *) buff;
hdr->nlmsg_len = MESSAGE_SIZE;
hdr->nlmsg_type = NLMSG_DONE;
hdr->nlmsg_flags = 0;
hdr->nlmsg_seq = 0;
hdr->nlmsg_pid = getpid();
/* the message */
msg = (struct cn_msg *) NLMSG_DATA(hdr);
msg->id.idx = CN_IDX_FORK;
msg->id.val = CN_VAL_FORK;
msg->seq = 0;
msg->ack = 0;
msg->len = sizeof(int);
msg->data[0] = action;
send(sock, hdr, hdr->nlmsg_len, 0);
}
static void cleanup()
{
struct timeval tmp_time;
switch_cn_fork(sock, CN_FORK_OFF);
tmp_time = test_time;
gettimeofday(_time, NULL);
printf("%lu processes were created in %li seconds.\n",
total_p, test_time.tv_sec - tmp_time.tv_sec);
close(sock);
exit(EXIT_SUCCESS);
}
int main()
{
int err;
struct sockaddr_nl sa; /* information for NETLINK interface */
/*
* To be able to quit the application properly we install a
* signal handler that catch the CTRL-C
*/
signal(SIGTERM, cleanup);
signal(SIGINT, cleanup);
/*
* Create an endpoint for communication. Use the kernel user
* interface device (PF_NETLINK) which is a datagram oriented
* service (SOCK_DGRAM). The protocol used is the netfilter/iptables
* ULOG protocol (NETLINK_NFLOG)
*/
sock = socket(PF_NETLINK
Re: [Lse-tech] Re: A common layer for Accounting packages
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 message. > > I'm also trying to mesure the process-creation/destruction performance on > following three environment. > Archtechture: i686 / Distribution: Fedora Core 3 > * Kernel Preemption is DISABLE > * SMP kernel but UP-machine / Not Hyper Threading > [1] 2.6.11-rc4-mm1 normal > [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module > [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) > > When 367th-fork() was called after fork-connector notification, kernel was > locked up. > (User-Space-Listener has been also run until 366th-fork() notification was > received) 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-cnfork o Second line is a linux-2.6.11-rc4-mm1 o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space application. The user space application listened during 15h and received 6496 messages. Each test has been ran only once. Best regards, Guillaume --- cd results && make summary percent 2>/dev/null | more make[1]: Entering directory `/home/guill/benchmark/lmbench/lmbench-3.0-a4/results' L M B E N C H 3 . 0 S U M M A R Y (Alpha software, do not distribute) Basic system parameters -- Host OS Description Mhz tlb cache mem scal pages line par load bytes - - --- - - -- account Linux 2.6.11- i686-pc-linux-gnu 276563 128 2.49001 account Linux 2.6.11- i686-pc-linux-gnu 276567 128 2.42001 account Linux 2.6.11- i686-pc-linux-gnu 276569 128 2.44001 Processor, Processes - times in microseconds - smaller is better -- Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc - - account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629. 2415 account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628. 2417 account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664. 2456 Basic integer operations - times in nanoseconds - smaller is better --- Host OS intgr intgr intgr intgr intgr bit addmuldivmod - - -- -- -- -- -- account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 Basic float operations - times in nanoseconds - smaller is better - Host OS float float float float addmuldivbogo - - -- -- -- -- account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Basic double operations - times in nanoseconds - smaller is better -- Host OS double double double double addmuldivbogo - - -- -- -- -- account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Context switching - times in microseconds - smaller is better - Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw - - -- -- -- -- -- --- --- account Linux 2.6.11- 5.1300 5.2900 4.9700 3.1700 10.9 6.332.6 account Linux 2.6.11- 4.9000 5.2100 5.1600 4.4700 20.3 6.4800027.7 account Linux 2.6.11- 4.8600 5.3000 4.9200 3.5600 20.5 6.8700031.5 *Local* Communication
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
ChangeLog:
- Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
in the CN_FORK_MSG_SIZE macro
- fork_cn_lock is declareed with DEFINE_SPINLOCK()
- fork_cn_lock is defined as static and local to fork_connector()
- Create a specific module cn_fork.c in drivers/connector to
register the callback.
- Improve the callback that turns on/off the fork connector
I also run the lmbench and results are send in response to another
thread "A common layer for Accounting packages". When fork connector is
turned off the overhead is negligible. 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 Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c
--- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01
13:13:05.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 it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable)))
+ memcpy(_fork_enable, msg->data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(_fork_id, "cn_fork", _fork_callback);
+ if (err) {
+ printk(KERN_WARNING "Failed to register cn_fork\n");
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE "cn_fork is registered\n");
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
+ *
+ * As this driver is always statically compiled into the kernel the
+ * cn_fork_exit has no effect.
+ */
+static void cn_fork_exit(void)
+{
+ cn_del_callback(_fork_id);
+}
+
+module_init(cn_fork_init);
+module_exit(cn_fork_exit);
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig 2005-02-24
10:29:11.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
ChangeLog:
- Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
in the CN_FORK_MSG_SIZE macro
- fork_cn_lock is declareed with DEFINE_SPINLOCK()
- fork_cn_lock is defined as static and local to fork_connector()
- Create a specific module cn_fork.c in drivers/connector to
register the callback.
- Improve the callback that turns on/off the fork connector
I also run the lmbench and results are send in response to another
thread A common layer for Accounting packages. When fork connector is
turned off the overhead is negligible. 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 Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11 +
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 85
include/linux/connector.h |4 ++
kernel/fork.c | 44 ++
5 files changed, 145 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c
--- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01
13:13:05.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 it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
+ * about fork in the do_fork() routine. To enable the fork, the user
+ * space application must send the integer 1 in the data part of the
+ * message. To disable the fork connector, it must send the integer 0.
+ */
+static void cn_fork_callback(void *data)
+{
+ struct cn_msg *msg = (struct cn_msg *)data;
+
+ if (cn_already_initialized (msg-len == sizeof(cn_fork_enable)))
+ memcpy(cn_fork_enable, msg-data, sizeof(cn_fork_enable));
+}
+
+/**
+ * cn_fork_init - initialization entry point
+ *
+ * This routine will be run at kernel boot time because this driver is
+ * built in the kernel. It adds the connector callback to the connector
+ * driver.
+ */
+static int cn_fork_init(void)
+{
+ int err;
+
+ err = cn_add_callback(cb_fork_id, cn_fork, cn_fork_callback);
+ if (err) {
+ printk(KERN_WARNING Failed to register cn_fork\n);
+ return -EINVAL;
+ }
+
+ printk(KERN_NOTICE cn_fork is registered\n);
+ return 0;
+}
+
+/**
+ * cn_fork_exit - exit entry point
+ *
+ * As this driver is always statically compiled into the kernel the
+ * cn_fork_exit has no effect.
+ */
+static void cn_fork_exit(void)
+{
+ cn_del_callback(cb_fork_id);
+}
+
+module_init(cn_fork_init);
+module_exit(cn_fork_exit);
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig 2005-02-24
10:29:11.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child
Re: [Lse-tech] Re: A common layer for Accounting packages
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 message. I'm also trying to mesure the process-creation/destruction performance on following three environment. Archtechture: i686 / Distribution: Fedora Core 3 * Kernel Preemption is DISABLE * SMP kernel but UP-machine / Not Hyper Threading [1] 2.6.11-rc4-mm1 normal [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) When 367th-fork() was called after fork-connector notification, kernel was locked up. (User-Space-Listener has been also run until 366th-fork() notification was received) 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-cnfork o Second line is a linux-2.6.11-rc4-mm1 o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space application. The user space application listened during 15h and received 6496 messages. Each test has been ran only once. Best regards, Guillaume --- cd results make summary percent 2/dev/null | more make[1]: Entering directory `/home/guill/benchmark/lmbench/lmbench-3.0-a4/results' L M B E N C H 3 . 0 S U M M A R Y (Alpha software, do not distribute) Basic system parameters -- Host OS Description Mhz tlb cache mem scal pages line par load bytes - - --- - - -- account Linux 2.6.11- i686-pc-linux-gnu 276563 128 2.49001 account Linux 2.6.11- i686-pc-linux-gnu 276567 128 2.42001 account Linux 2.6.11- i686-pc-linux-gnu 276569 128 2.44001 Processor, Processes - times in microseconds - smaller is better -- Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc - - account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629. 2415 account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628. 2417 account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664. 2456 Basic integer operations - times in nanoseconds - smaller is better --- Host OS intgr intgr intgr intgr intgr bit addmuldivmod - - -- -- -- -- -- account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 Basic float operations - times in nanoseconds - smaller is better - Host OS float float float float addmuldivbogo - - -- -- -- -- account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Basic double operations - times in nanoseconds - smaller is better -- Host OS double double double double addmuldivbogo - - -- -- -- -- account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Context switching - times in microseconds - smaller is better - Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw - - -- -- -- -- -- --- --- account Linux 2.6.11- 5.1300 5.2900 4.9700 3.1700 10.9 6.332.6 account Linux 2.6.11- 4.9000 5.2100 5.1600 4.4700 20.3 6.4800027.7 account Linux 2.6.11- 4.8600 5.3000 4.9200 3.5600 20.5 6.8700031.5 *Local* Communication latencies in microseconds -
Re: [Lse-tech] Re: A common layer for Accounting packages
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 are:
o First line is a linux-2.6.11-rc4-mm1-cnfork
o Second line is a linux-2.6.11-rc4-mm1
o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space
application. The user space application listened during 15h
and received 6496 messages.
Each test has been ran only once.
...
--
Host OS Mhz null null open slct sig sig fork exec
sh
call I/O stat clos TCP inst hndl proc proc
proc
- -
account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629.
2415
account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628.
2417
account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664.
2456
This is the interesting bit, yes? 5-10% slowdown on fork is expected, but
why was exec slower?
I can't explain it for the moment. I will run test more than once to see
if this difference is still here.
What does The user space application listened during 15h mean?
It means that I ran the user space application before the test and
stop it 15 hours later (this morning for me). The test ran during
5h30mn.
The user space application increments a counter to show how many
processes have been created during a period of time. I have not use the
user space daemon that manages group of processes because the it still
uses the old mechanism (a signal sends from the do_fork()) and as I
wanted to provide quick results, I used another user space application.
I attache the test program (get_fork_info.c) that I'm using at the end
of the mail to clearly show what it does.
I will run new tests with the real user space daemon but it will be
ready next week, sorry for the delay.
Best regards,
Guillaume
---
/*
* get_fork_info.c
*
* This program listens netlink interface to retreive information
* sends by the kernel when forking. It increments a counter for
* each forks and when the user hit CRL-C, it displays how many
* fork occured during the period.
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include string.h
#include errno.h
#include signal.h
#include asm/types.h
#include sys/types.h
#include sys/socket.h
#include sys/time.h
#include linux/netlink.h
#include linux/connector.h
#define CN_FORK_OFF 0
#define CN_FORK_ON 1
#define MESSAGE_SIZE(sizeof(struct nlmsghdr) + \
sizeof(struct cn_msg) + \
sizeof(int))
int sock;
unsigned long total_p;
struct timeval test_time;
static inline void switch_cn_fork(int sock, int action)
{
char buff[128]; /* must be MESSAGE_SIZE */
struct nlmsghdr *hdr;
struct cn_msg *msg;
/* Clear the buffer */
memset(buff, '\0', sizeof(buff));
/* fill the message header */
hdr = (struct nlmsghdr *) buff;
hdr-nlmsg_len = MESSAGE_SIZE;
hdr-nlmsg_type = NLMSG_DONE;
hdr-nlmsg_flags = 0;
hdr-nlmsg_seq = 0;
hdr-nlmsg_pid = getpid();
/* the message */
msg = (struct cn_msg *) NLMSG_DATA(hdr);
msg-id.idx = CN_IDX_FORK;
msg-id.val = CN_VAL_FORK;
msg-seq = 0;
msg-ack = 0;
msg-len = sizeof(int);
msg-data[0] = action;
send(sock, hdr, hdr-nlmsg_len, 0);
}
static void cleanup()
{
struct timeval tmp_time;
switch_cn_fork(sock, CN_FORK_OFF);
tmp_time = test_time;
gettimeofday(test_time, NULL);
printf(%lu processes were created in %li seconds.\n,
total_p, test_time.tv_sec - tmp_time.tv_sec);
close(sock);
exit(EXIT_SUCCESS);
}
int main()
{
int err;
struct sockaddr_nl sa; /* information for NETLINK interface */
/*
* To be able to quit the application properly we install a
* signal handler that catch the CTRL-C
*/
signal(SIGTERM, cleanup);
signal(SIGINT, cleanup);
/*
* Create an endpoint for communication. Use the kernel user
* interface device (PF_NETLINK) which is a datagram oriented
* service (SOCK_DGRAM). The protocol used is the netfilter/iptables
* ULOG protocol (NETLINK_NFLOG)
*/
sock = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_NFLOG);
if (sock == -1) {
perror(socket);
return -1;
}
sa.nl_family = AF_NETLINK;
sa.nl_groups = CN_IDX_FORK
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 wrapper, which > would then call do_exit_csa() for CSA and call do_acct_process > for BSD. Is it possible to merge BSD and CSA? I mean with CSA, there is a part that does per-process accounting. For exemple in the linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and csa_update_integrals() update fields in the current (and parent) process. So maybe you can improve the BSD per-process accounting or maybe CSA can replace the BSD per-process accounting? 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 message.
>
> I'm also trying to mesure the process-creation/destruction performance on
> following three environment.
> Archtechture: i686 / Distribution: Fedora Core 3
> * Kernel Preemption is DISABLE
> * SMP kernel but UP-machine / Not Hyper Threading
> [1] 2.6.11-rc4-mm1 normal
> [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module
> [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled)
>
> When 367th-fork() was called after fork-connector notification, kernel was
> locked up.
> (User-Space-Listener has been also run until 366th-fork() notification was
> received)
I don't see this limit on my computer. I'm currently running the lmbench
with a new fork connector patch (one that enable/disable fork connector)
on an SMP computer. I will send results and the new patch tomorrow
because the test takes a while...
I'm using a small patch provided by Evgeniy and not included in the
2.6.11-rc4-mm1 tree.
Best regards,
Guillaume
--- orig/connector.c
+++ mod/connector.c
@@ -168,12 +168,11 @@
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) {
printk(KERN_ERR "skb does not have enough length: "
- "requested msg->len=%u[%u],
nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n",
- msg->len, NLMSG_SPACE(msg->len),
- nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh),
- skb->len, msg->len + sizeof(*msg));
+ "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
+ msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
+ nlh->nlmsg_len, skb->len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 dont even have skbs built nor > > even figured out what sock or PID. That work still needs to be done it > > seems in cn_netlink_send(). So probably all they need to do is move the > > check in cn_netlink_send() instead. This is assuming they are not > > scratching their heads with some realted complexities. > [...] > As connector author, I still doubt it worth copying several lines > from netlink_broadcast() before skb allocation in cn_netlink_send(). > Of course it is easy and can be done, but I do not 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 connector's cost is negligible > both with and without userspace listeners. > As far as I remember it is first entry in fork connector's TODO list. 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. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 dont even have skbs built nor even figured out what sock or PID. That work still needs to be done it seems in cn_netlink_send(). So probably all they need to do is move the check in cn_netlink_send() instead. This is assuming they are not scratching their heads with some realted complexities. [...] As connector author, I still doubt it worth copying several lines from netlink_broadcast() before skb allocation in cn_netlink_send(). Of course it is easy and can be done, but I do not 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 connector's cost is negligible both with and without userspace listeners. As far as I remember it is first entry in fork connector's TODO list. 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. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 message.
I'm also trying to mesure the process-creation/destruction performance on
following three environment.
Archtechture: i686 / Distribution: Fedora Core 3
* Kernel Preemption is DISABLE
* SMP kernel but UP-machine / Not Hyper Threading
[1] 2.6.11-rc4-mm1 normal
[2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module
[3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled)
When 367th-fork() was called after fork-connector notification, kernel was
locked up.
(User-Space-Listener has been also run until 366th-fork() notification was
received)
I don't see this limit on my computer. I'm currently running the lmbench
with a new fork connector patch (one that enable/disable fork connector)
on an SMP computer. I will send results and the new patch tomorrow
because the test takes a while...
I'm using a small patch provided by Evgeniy and not included in the
2.6.11-rc4-mm1 tree.
Best regards,
Guillaume
--- orig/connector.c
+++ mod/connector.c
@@ -168,12 +168,11 @@
group = NETLINK_CB((skb)).groups;
msg = (struct cn_msg *)NLMSG_DATA(nlh);
- if (msg-len != nlh-nlmsg_len - sizeof(*msg) - sizeof(*nlh)) {
+ if (NLMSG_SPACE(msg-len + sizeof(*msg)) != nlh-nlmsg_len) {
printk(KERN_ERR skb does not have enough length:
- requested msg-len=%u[%u],
nlh-nlmsg_len=%u[%u], skb-len=%u[must be %u].\n,
- msg-len, NLMSG_SPACE(msg-len),
- nlh-nlmsg_len, nlh-nlmsg_len - sizeof(*nlh),
- skb-len, msg-len + sizeof(*msg));
+ requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
+ msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
+ nlh-nlmsg_len, skb-len);
kfree_skb(skb);
return -EINVAL;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 wrapper, which would then call do_exit_csa() for CSA and call do_acct_process for BSD. Is it possible to merge BSD and CSA? I mean with CSA, there is a part that does per-process accounting. For exemple in the linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and csa_update_integrals() update fields in the current (and parent) process. So maybe you can improve the BSD per-process accounting or maybe CSA can replace the BSD per-process accounting? 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 accounting data, it needs the CSA > eop handling at exit as well. Why replace the acct_process()? The problem here is to add a new hook in the do_fork() and you can use the BSD accounting hook acct_process() which is already in the exit() routine. We don't need to replace it with a netlink because today there are no user space applications that need it. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 accounting data, it needs the CSA eop handling at exit as well. Why replace the acct_process()? The problem here is to add a new hook in the do_fork() and you can use the BSD accounting hook acct_process() which is already in the exit() routine. We don't need to replace it with a netlink because today there are no user space applications that need it. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 myself.
>
> If we notify the fork/exec/exit-events to user-space directly as you said,
> I don't think some hackings on netlink is necessary.
> For example, such packets is sent only when /proc/sys/.../process_grouping is
> set,
> and user-side daemon set this value, and unset when daemon will exit.
> It's not necessary to take too seriously.
I wrote a new fork connector patch with a callback to enable/disable
messages in case there is or isn't listener. I will post it this week.
Basically there is a global variable that is manipulated with a
connector callback so a user space daemon can manipulate the variable.
In the fork_connector() function you have:
static inline void fork_connector(pid_t parent, pid_t child)
{
static DEFINE_SPINLOCK(cn_fork_lock);
static __u32 seq; /* used to test if message is lost */
if (cn_fork_enable) {
[...]
cn_netlink_send(msg, CN_IDX_FORK);
}
}
and in the cn_fork module (drivers/connector/cn_fork.c) the callback is
defined as:
static void cn_fork_callback(void *data)
{
if (cn_already_initialized)
cn_fork_enable = cn_fork_enable ? 0 : 1;
}
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 application are using the fork connector one can
enable it and the other don't know if it is enable or not, but the idea
is here I think.
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 myself.
If we notify the fork/exec/exit-events to user-space directly as you said,
I don't think some hackings on netlink is necessary.
For example, such packets is sent only when /proc/sys/.../process_grouping is
set,
and user-side daemon set this value, and unset when daemon will exit.
It's not necessary to take too seriously.
I wrote a new fork connector patch with a callback to enable/disable
messages in case there is or isn't listener. I will post it this week.
Basically there is a global variable that is manipulated with a
connector callback so a user space daemon can manipulate the variable.
In the fork_connector() function you have:
static inline void fork_connector(pid_t parent, pid_t child)
{
static DEFINE_SPINLOCK(cn_fork_lock);
static __u32 seq; /* used to test if message is lost */
if (cn_fork_enable) {
[...]
cn_netlink_send(msg, CN_IDX_FORK);
}
}
and in the cn_fork module (drivers/connector/cn_fork.c) the callback is
defined as:
static void cn_fork_callback(void *data)
{
if (cn_already_initialized)
cn_fork_enable = cn_fork_enable ? 0 : 1;
}
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 application are using the fork connector one can
enable it and the other don't know if it is enable or not, but the idea
is here I think.
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 before a task_struct is disposed. > > > > This patch is to modify the acct_process() in acct.c, which is > > invoked from do_exit() to handle eop for BSD accounting. Now > > the acct_process() wrapper will also take care of CSA, if it has > > been loaded. If the CSA module has been loaded, a CSA routine > > will be invoked to construct a CSA job record and to write the > > record to the CSA accounting file. > > I really don't want to have to (and shouldn't need to) become an accounting > person, but as there seems to be a communication problem somewhere.. > > Please, you guys are the subject matter experts. Put your heads together > and come up with something. I completely agree with that and we will continue this conversation in private with Jay and all people involved to come up with an appropriate solution. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
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 technical objections... > But I really would like to see your second and third TODO entries in > ChangeLog before you will push it upstream. Yes, I agree with that and I'm working on those two points. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. It applies on a kernel
2.6.11-rc4-mm1. The connector sends information about parent PID and
child PID over a netlink interface. It allows to several user space
applications to be informed when a fork occurs in the kernel. The main
drawback is that even if nobody listens, message is send. I don't know
how to avoid that.
It is used by ELSA to manage group of processes in user space and can
be used by any other user space application that needs this kind of
information.
I add a callback that turns on/off the fork connector. It's a very
simple mechanism and, as Evgeniy suggested, it may need a more complex
protocol.
ChangeLog:
- "fork_id" is now declared as a static const
- Replace snprintf() by scnprintf()
- Protect "seq" by a spin lock because the seq number can be
used by the daemon to check if all forks are intercepted
- "msg" send is now local
- Add a callback that turns on/off the fork connector.
- memset is only used to clear the msg->data part instead of all
message.
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 PROTECTED]>
---
drivers/connector/Kconfig | 11 ++
drivers/connector/connector.c | 20 ++
include/linux/connector.h |3 ++
kernel/fork.c | 45 ++
4 files changed, 79 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/connector.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/connector.c
--- linux-2.6.11-rc4-mm1/drivers/connector/connector.c 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/connector.c 2005-02-24
10:21:59.0 +0100
@@ -45,8 +45,10 @@ static DEFINE_SPINLOCK(notify_lock);
static LIST_HEAD(notify_list);
static struct cn_dev cdev;
+static struct cb_id cn_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
int cn_already_initialized = 0;
+int cn_fork_enable = 0;
/*
* msg->seq and msg->ack are used to determine message genealogy.
@@ -467,6 +469,14 @@ static void cn_callback(void * data)
}
}
+static void cn_fork_callback(void *data)
+{
+ if (cn_already_initialized)
+ cn_fork_enable = cn_fork_enable ? 0 : 1;
+
+ printk(KERN_NOTICE "cn_fork_enable is set to %i\n", cn_fork_enable);
+}
+
static int cn_init(void)
{
struct cn_dev *dev =
@@ -498,6 +508,15 @@ static int cn_init(void)
return -EINVAL;
}
+ err = cn_add_callback(_fork_id, "cn_fork", _fork_callback);
+ if (err) {
+ cn_del_callback(>id);
+ cn_queue_free_dev(dev->cbdev);
+ if (dev->nls->sk_socket)
+ sock_release(dev->nls->sk_socket);
+ return -EINVAL;
+ }
+
cn_already_initialized = 1;
return 0;
@@ -507,6 +526,7 @@ static void cn_fini(void)
{
struct cn_dev *dev =
+ cn_del_callback(_fork_id);
cn_del_callback(>id);
cn_queue_free_dev(dev->cbdev);
if (dev->nls->sk_socket)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig 2005-02-24
10:29:11.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/include/linux/connector.h
linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h
--- linux-2.6.11-rc4-mm1/include/linux/connector.h 2005-02-23
11:12:17.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h 2005-02-24
10:25:22.0 +0100
@@ -28,6 +28,8 @@
#define CN_VAL_KOBJECT_UEVENT 0x
#define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
#define CN_VAL_
[PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. It applies on a kernel
2.6.11-rc4-mm1. The connector sends information about parent PID and
child PID over a netlink interface. It allows to several user space
applications to be informed when a fork occurs in the kernel. The main
drawback is that even if nobody listens, message is send. I don't know
how to avoid that.
It is used by ELSA to manage group of processes in user space and can
be used by any other user space application that needs this kind of
information.
I add a callback that turns on/off the fork connector. It's a very
simple mechanism and, as Evgeniy suggested, it may need a more complex
protocol.
ChangeLog:
- fork_id is now declared as a static const
- Replace snprintf() by scnprintf()
- Protect seq by a spin lock because the seq number can be
used by the daemon to check if all forks are intercepted
- msg send is now local
- Add a callback that turns on/off the fork connector.
- memset is only used to clear the msg-data part instead of all
message.
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 PROTECTED]
---
drivers/connector/Kconfig | 11 ++
drivers/connector/connector.c | 20 ++
include/linux/connector.h |3 ++
kernel/fork.c | 45 ++
4 files changed, 79 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/connector.c
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/connector.c
--- linux-2.6.11-rc4-mm1/drivers/connector/connector.c 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/connector.c 2005-02-24
10:21:59.0 +0100
@@ -45,8 +45,10 @@ static DEFINE_SPINLOCK(notify_lock);
static LIST_HEAD(notify_list);
static struct cn_dev cdev;
+static struct cb_id cn_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
int cn_already_initialized = 0;
+int cn_fork_enable = 0;
/*
* msg-seq and msg-ack are used to determine message genealogy.
@@ -467,6 +469,14 @@ static void cn_callback(void * data)
}
}
+static void cn_fork_callback(void *data)
+{
+ if (cn_already_initialized)
+ cn_fork_enable = cn_fork_enable ? 0 : 1;
+
+ printk(KERN_NOTICE cn_fork_enable is set to %i\n, cn_fork_enable);
+}
+
static int cn_init(void)
{
struct cn_dev *dev = cdev;
@@ -498,6 +508,15 @@ static int cn_init(void)
return -EINVAL;
}
+ err = cn_add_callback(cn_fork_id, cn_fork, cn_fork_callback);
+ if (err) {
+ cn_del_callback(dev-id);
+ cn_queue_free_dev(dev-cbdev);
+ if (dev-nls-sk_socket)
+ sock_release(dev-nls-sk_socket);
+ return -EINVAL;
+ }
+
cn_already_initialized = 1;
return 0;
@@ -507,6 +526,7 @@ static void cn_fini(void)
{
struct cn_dev *dev = cdev;
+ cn_del_callback(cn_fork_id);
cn_del_callback(dev-id);
cn_queue_free_dev(dev-cbdev);
if (dev-nls-sk_socket)
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig
linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23
11:12:15.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig 2005-02-24
10:29:11.0 +0100
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/include/linux/connector.h
linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h
--- linux-2.6.11-rc4-mm1/include/linux/connector.h 2005-02-23
11:12:17.0 +0100
+++ linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h 2005-02-24
10:25:22.0 +0100
@@ -28,6 +28,8 @@
#define CN_VAL_KOBJECT_UEVENT 0x
#define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
#define CN_VAL_SUPERIO 0xccdd
+#define CN_IDX_FORK0xfeed /* fork events */
+#define
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
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 technical objections... But I really would like to see your second and third TODO entries in ChangeLog before you will push it upstream. Yes, I agree with that and I'm working on those two points. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
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 before a task_struct is disposed. This patch is to modify the acct_process() in acct.c, which is invoked from do_exit() to handle eop for BSD accounting. Now the acct_process() wrapper will also take care of CSA, if it has been loaded. If the CSA module has been loaded, a CSA routine will be invoked to construct a CSA job record and to write the record to the CSA accounting file. I really don't want to have to (and shouldn't need to) become an accounting person, but as there seems to be a communication problem somewhere.. Please, you guys are the subject matter experts. Put your heads together and come up with something. I completely agree with that and we will continue this conversation in private with Jay and all people involved to come up with an appropriate solution. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 be done > > with the fork connector patch. > > I am not quite comfortable of ELSA requesting a fork hook this way. > How many hooks in the stock kernel that are related to accounting? Can > anyone answer this question? I know of 'acct_process()' in exit.c used > by the BSD accounting and ELSA is requesting a hook in fork. If people > raise the same question again a few years later, how many people will > still remember this ELSA hook? The fork connector is not related to accounting. It's a connector that allows to send information to a user space application when a fork occurs in the kernel. This information is used by ELSA by I think that this hook will be used by some others user space applications and IMHO, it's not incompatible with a specific hook for accounting tool if needed. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 to the fork_connector
> > subsystem turning it on or off. So we can bypass all this code in the
> > common case where is listening, but your daemon is
> > not.
>
> Ok, now I see(I'm not a fork connector author, so I did not receive them).
> That will require to add real fork connector with callback routing.
> Guillaume?
Yes the connector's callback is a good solution. I will add a fork
enable/disable callback in drivers/connector/connector.c that will
switch a global variable when called from user space. It will be
something like:
void cn_fork_callback(void)
{
if (cn_already_initialized)
cn_fork_enable = cn_fork_enable ? 0 : 1 ;
}
With cn_fork_enable set to 0 by default. In the do_fork() I will replace
the statement "if (cn_already_initialized)" by "if (cn_fork_enable)"
> > Without a lock you can have two messages with the same sequence number.
> > Even if the daemon which you're planning on implementing can handle that,
> > we shouldn't allow it.
>
> Yes, they can have the same number, but does it cost atomic/lock overhead?
> Anyway, simple spin_lock() should be enough in do_fork() context.
> Guillaume?
I will protect the incrementation by a spin_lock(_cn_lock).
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 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? Yes, that's correct. All I need is the fork connector patch. It needs more work like, as you said, sending an on/off message down the netlink socket. I'm working on this (thank you very much Andrew for your comments). I will run benchmarks found at http://bulk.fefe.de/scalability/ to see how the fork connector impacts on the kernel. All stuff that was previously done in kernel space and provided by the 2.6.8.1 ELSA patch has been moved in the ELSA user space daemon called "jobd". Best, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
Hello,
This patch replaces the relay_fork module and it 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 informed when a fork
occurs in the kernel. The main drawback is that even if nobody listens,
message is send. I don't know how to avoid that.
It is used by ELSA to manage group of processes in user space.
ChangeLog:
- Add a "depends on CONNECTOR=y" in the Kconfig
- Remove the macro #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/connector.h |2 ++
kernel/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 2005-02-11
11:00:16.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig 2005-02-21
09:52:22.0 +0100
@@ -10,4 +10,12 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+
endmenu
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/include/linux/connector.h
linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h
--- linux-2.6.11-rc3-mm2/include/linux/connector.h 2005-02-11
11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h 2005-02-16
15:07:46.0 +0100
@@ -28,6 +28,8 @@
#define CN_VAL_KOBJECT_UEVENT 0x
#define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
#define CN_VAL_SUPERIO 0xccdd
+#define CN_IDX_FORK0xfeed /* fork events */
+#define CN_VAL_FORK0xbeef
#define CONNECTOR_MAX_MSG_SIZE 1024
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/kernel/fork.c
linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c
--- linux-2.6.11-rc3-mm2/kernel/fork.c 2005-02-11 11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c 2005-02-21 09:52:40.0
+0100
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -63,6 +64,44 @@ DEFINE_PER_CPU(unsigned long, process_co
EXPORT_SYMBOL(tasklist_lock);
+#ifdef CONFIG_FORK_CONNECTOR
+#define FORK_CN_INFO_SIZE 64
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
+ static __u32 seq; /* used to test if we lost message */
+
+ if (cn_already_initialized) {
+ struct cn_msg *msg;
+ size_t size;
+
+ size = sizeof(*msg) + FORK_CN_INFO_SIZE;
+ msg = kmalloc(size, GFP_KERNEL);
+ if (msg) {
+ memset(msg, '\0', size);
+ memcpy(>id, _id, sizeof(msg->id));
+ msg->seq = seq++;
+ msg->ack = 0; /* not used */
+ /*
+* size of data is the number of characters
+* printed plus one for the trailing '\0'
+*/
+ msg->len = snprintf(msg->data, FORK_CN_INFO_SIZE-1,
+ "%i %i", parent, child) + 1;
+
+ cn_netlink_send(msg, CN_IDX_FORK);
+
+ kfree(msg);
+ }
+ }
+}
+#else
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ return;
+}
+#endif
+
int nr_processes(void)
{
int cpu;
@@ -1238,6 +1277,8 @@ long do_fork(unsigned long clone_flags,
if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) |
SIGTRAP);
}
+
+ fork_connector(current->pid, p->pid);
} else {
free_pidmap(pid);
pid = PTR_ERR(p);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 its diverseness. > > > > For example, a process which belong to JOB-A must not belong any other > > 'JOB-X' in CSA-model. But, In ELSA-model, a process in BANK-B can > > concurrently > > belong to BANK-B1 which is a child of BANK-B. > > > > And, there are other defferences: > > Whether a process not to belong to any process-aggregation is permitted or > > not ? > > Whether a process-aggregation should be inherited to child process or not ? > > (There is possibility not to be inherited in a rule-based process > > aggregation like CKRM) > > > > 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. I can add "policies". With ELSA, a process belongs to one or several groups and if a process is removed from one group, its children still belong to the group. Thus a good idea could be to associate a "philosophy" to a group. For exemple, when a group of processes is created it can be tagged as UNIQUE or SHARED. UNIQUE means that a process that belongs to it could not be added in another group by opposition to SHARED. It's not needed inside the kernel. > 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. > (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. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 its diverseness. For example, a process which belong to JOB-A must not belong any other 'JOB-X' in CSA-model. But, In ELSA-model, a process in BANK-B can concurrently belong to BANK-B1 which is a child of BANK-B. And, there are other defferences: Whether a process not to belong to any process-aggregation is permitted or not ? Whether a process-aggregation should be inherited to child process or not ? (There is possibility not to be inherited in a rule-based process aggregation like CKRM) 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. I can add policies. With ELSA, a process belongs to one or several groups and if a process is removed from one group, its children still belong to the group. Thus a good idea could be to associate a philosophy to a group. For exemple, when a group of processes is created it can be tagged as UNIQUE or SHARED. UNIQUE means that a process that belongs to it could not be added in another group by opposition to SHARED. It's not needed inside the kernel. 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. (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. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
Hello,
This patch replaces the relay_fork module and it 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 informed when a fork
occurs in the kernel. The main drawback is that even if nobody listens,
message is send. I don't know how to avoid that.
It is used by ELSA to manage group of processes in user space.
ChangeLog:
- Add a depends on CONNECTOR=y in the Kconfig
- Remove the macro #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/connector.h |2 ++
kernel/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 2005-02-11
11:00:16.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig 2005-02-21
09:52:22.0 +0100
@@ -10,4 +10,12 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+
endmenu
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/include/linux/connector.h
linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h
--- linux-2.6.11-rc3-mm2/include/linux/connector.h 2005-02-11
11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h 2005-02-16
15:07:46.0 +0100
@@ -28,6 +28,8 @@
#define CN_VAL_KOBJECT_UEVENT 0x
#define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
#define CN_VAL_SUPERIO 0xccdd
+#define CN_IDX_FORK0xfeed /* fork events */
+#define CN_VAL_FORK0xbeef
#define CONNECTOR_MAX_MSG_SIZE 1024
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/kernel/fork.c
linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c
--- linux-2.6.11-rc3-mm2/kernel/fork.c 2005-02-11 11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c 2005-02-21 09:52:40.0
+0100
@@ -41,6 +41,7 @@
#include linux/profile.h
#include linux/rmap.h
#include linux/acct.h
+#include linux/connector.h
#include asm/pgtable.h
#include asm/pgalloc.h
@@ -63,6 +64,44 @@ DEFINE_PER_CPU(unsigned long, process_co
EXPORT_SYMBOL(tasklist_lock);
+#ifdef CONFIG_FORK_CONNECTOR
+#define FORK_CN_INFO_SIZE 64
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
+ static __u32 seq; /* used to test if we lost message */
+
+ if (cn_already_initialized) {
+ struct cn_msg *msg;
+ size_t size;
+
+ size = sizeof(*msg) + FORK_CN_INFO_SIZE;
+ msg = kmalloc(size, GFP_KERNEL);
+ if (msg) {
+ memset(msg, '\0', size);
+ memcpy(msg-id, fork_id, sizeof(msg-id));
+ msg-seq = seq++;
+ msg-ack = 0; /* not used */
+ /*
+* size of data is the number of characters
+* printed plus one for the trailing '\0'
+*/
+ msg-len = snprintf(msg-data, FORK_CN_INFO_SIZE-1,
+ %i %i, parent, child) + 1;
+
+ cn_netlink_send(msg, CN_IDX_FORK);
+
+ kfree(msg);
+ }
+ }
+}
+#else
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ return;
+}
+#endif
+
int nr_processes(void)
{
int cpu;
@@ -1238,6 +1277,8 @@ long do_fork(unsigned long clone_flags,
if (unlikely (current-ptrace PT_TRACE_VFORK_DONE))
ptrace_notify ((PTRACE_EVENT_VFORK_DONE 8) |
SIGTRAP);
}
+
+ fork_connector(current-pid, p-pid);
} else {
free_pidmap(pid);
pid = PTR_ERR(p);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 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? Yes, that's correct. All I need is the fork connector patch. It needs more work like, as you said, sending an on/off message down the netlink socket. I'm working on this (thank you very much Andrew for your comments). I will run benchmarks found at http://bulk.fefe.de/scalability/ to see how the fork connector impacts on the kernel. All stuff that was previously done in kernel space and provided by the 2.6.8.1 ELSA patch has been moved in the ELSA user space daemon called jobd. Best, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 userspace daemon to send a message to the fork_connector
subsystem turning it on or off. So we can bypass all this code in the
common case where secret application is listening, but your daemon is
not.
Ok, now I see(I'm not a fork connector author, so I did not receive them).
That will require to add real fork connector with callback routing.
Guillaume?
Yes the connector's callback is a good solution. I will add a fork
enable/disable callback in drivers/connector/connector.c that will
switch a global variable when called from user space. It will be
something like:
void cn_fork_callback(void)
{
if (cn_already_initialized)
cn_fork_enable = cn_fork_enable ? 0 : 1 ;
}
With cn_fork_enable set to 0 by default. In the do_fork() I will replace
the statement if (cn_already_initialized) by if (cn_fork_enable)
Without a lock you can have two messages with the same sequence number.
Even if the daemon which you're planning on implementing can handle that,
we shouldn't allow it.
Yes, they can have the same number, but does it cost atomic/lock overhead?
Anyway, simple spin_lock() should be enough in do_fork() context.
Guillaume?
I will protect the incrementation by a spin_lock(fork_cn_lock).
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 be done with the fork connector patch. I am not quite comfortable of ELSA requesting a fork hook this way. How many hooks in the stock kernel that are related to accounting? Can anyone answer this question? I know of 'acct_process()' in exit.c used by the BSD accounting and ELSA is requesting a hook in fork. If people raise the same question again a few years later, how many people will still remember this ELSA hook? The fork connector is not related to accounting. It's a connector that allows to send information to a user space application when a fork occurs in the kernel. This information is used by ELSA by I think that this hook will be used by some others user space applications and IMHO, it's not incompatible with a specific hook for accounting tool if needed. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 a hook at do_exit() to merge per-process data to per-job > data. How does ELSA handle this without a need of a do_exit() hook? There are three parts in ELSA. There is a job daemon that does process aggregation. It needs a hook in the do_fork() routine to be able to manage group of processes. So this part handles process-aggregation by maintaining a complete picture of the process/thread hierarchy. You can interact with the job daemon with classical IPC and message operations. Thus we wrote a second part that is the interface between the user and the job daemon. Through this interface you can add and remove a process in/from a group, you can stop the job daemon and you can dump information in a file about current group of processes. This file (that contains information about group of processes) is used by ELSA, with the accounting file provided by the accton(8) command and the BSD accounting, to provide per-group of process accounting. So the third part of ELSA is a parser and also an analyzer. The architecture of ELSA is as follow (I hope that the ASCII picture will be readable): KERNEL | USER SPACE | --- | --- | 1. Fork connector | Netlink | 2. Job Daemon | | |-->| | --- | --- | ^ | | IPC - | >| 3. Interface| | | (webmin, ...) |--- | --->| | | | | -| | Per-group of Accounting Fileprocesses (see accton(8))accounting You can see how it works on the following web page: http://elsa.sourceforge.net/sample_session.html In the session we're using the fork_history.ko which will be replace by the fork hook connector. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
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 a hook at do_exit() to merge per-process data to per-job data. How does ELSA handle this without a need of a do_exit() hook? There are three parts in ELSA. There is a job daemon that does process aggregation. It needs a hook in the do_fork() routine to be able to manage group of processes. So this part handles process-aggregation by maintaining a complete picture of the process/thread hierarchy. You can interact with the job daemon with classical IPC and message operations. Thus we wrote a second part that is the interface between the user and the job daemon. Through this interface you can add and remove a process in/from a group, you can stop the job daemon and you can dump information in a file about current group of processes. This file (that contains information about group of processes) is used by ELSA, with the accounting file provided by the accton(8) command and the BSD accounting, to provide per-group of process accounting. So the third part of ELSA is a parser and also an analyzer. The architecture of ELSA is as follow (I hope that the ASCII picture will be readable): KERNEL | USER SPACE | --- | --- | 1. Fork connector | Netlink | 2. Job Daemon | | |--| | --- | --- | ^ | | IPC - | | 3. Interface| | | (webmin, ...) |--- | ---| | | | | -| | Per-group of Accounting Fileprocesses (see accton(8))accounting You can see how it works on the following web page: http://elsa.sourceforge.net/sample_session.html In the session we're using the fork_history.ko which will be replace by the fork hook connector. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 alerted when a fork occurs in the kernel. > > Whoaa ... you're saying that because you might have several groups a > task could belong to at once, you'll use netlink to avoid managing lists > in the kernel. Seems that you're spending thousands of instructions to > save dozens. This is not a good trade off. I understand your point of view but I'm using netlink interface because it's already in the kernel so my choice is to use something that is already in the kernel instead of adding dozens of new instructions and also to do things in user space. The fork connector is here to move the management in the user space. Otherwise there is PAGG that manages group of processes in the kernel. To test performances, I tried to compile a kernel several times with and without the fork connector and here are the resource usage computed with the following command: time /bin/sh -c 'make O=/home/guill/build/k2610 oldconfig \ && make O=/home/guill/build/k2610 bzImage \ && make O=/home/guill/build/k2610 modules' between each test, the directory that contains object files was destroyed and a 'sync' was done. Results are: kernel without fork connector real : 8m17.042s 8m10.113s 8m08.597s 8m10.068s 8m08.930s user : 7m32.376s 7m35.985s 7m34.424s 7m34.221s 7m34.835s sys : 0m50.730s 0m51.139s 0m51.159s 0m51.406s 0m51.020s kernel with the fork connector real : 8m14.492s 8m08.656s 8m07.754s 8m08.002s 8m07.854s user : 7m31.664s 7m33.528s 7m33.625s 7m33.500s 7m33.822s sys : 0m50.651s 0m51.222s 0m51.102s 0m51.367s 0m50.894s kernel with the fork connector + application listens real : 8m08.596s 8m08.950s 8m08.899s 8m08.678s 8m08.987s user : 7m33.312s 7m33.898s 7m34.004s 7m33.285s 7m33.628s sys : 0m52.222s 0m52.013s 0m51.809s 0m52.361s 0m52.036s I also choose this implementation because Erich Focht wrote in the email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about the creation of processes "sounds very useful for a lot of interesting stuff". So I thought about something that can be used by other application and with netlink, information is available to everyone. > I can imagine several way cheaper ways to handle this. > > If the number of groups to which a task could belong has some small > finite upper limit, like at most 5 groups, you could have 5 integer id's > in the task struct instead of 1. If the number of elements in a > particular group has a small upper bound, you could even replace the > ints with bit fields. > > Or you could enumerate the different combinations of groups to which a > task might belong, assign each such combination a unique integer, and > keep that integer in the task struct. The enumeration could be done > dynamically, only counting the particular combinations of group > memberships that actually had use. This has the disadvantage that a > particular combination, once enumerated, would have to stay around until > the next boot - a potential memory leak. Probably not acceptable, > unless the cost of storing a no longer used combination is nearly zero. The problem with those solutions is that we suppose that a process can belong to a finite number of task. I suppose that it can be true in practice. > Or you could have a little 'jobids' struct that held a list and a > reference counter, where the list held a particular combination of ids, > and the reference counter tracked how many tasks referenced that jobids > struct. Put a single pointer in the task struct to a jobids struct, and > increment and decrement the reference counter in the jobids struct on > fork and exit. Free it if the count goes to zero on exit. This solves > the memory leak of the previous, with increased cost to the fork. Since > we really do design these systems to stay up 'forever', this is perhaps > the winner. Any time a particular task is added to, or removed from, a > group, if the ref count of its jobids struct is one, then modify the id > list attached to that jobids struct in place. If the ref count is more > than one, copy the jobids struct and list to a new one, decrement the > count in the old one, and modify the new one in place. Such list and > counter manipulations are the daily stuff of kernel code. No need to > avoid such. This solution is interesting. The problem is to know if a fork connector is useful for some other projects. As I said, one of my goal was to provide a way to alert user space application when a fork occurs in the kernel because I think that other applications need this kind of information. But if it is needed only by ELSA, you're right, a solution specific
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 a fork occurs and which processes are involved. I don't see how to
> > do this without a hook in the do_fork() routine...
>
> How is what you need, for process grouping, any more complex than
> another sort of {bank, job, aggregate, session, group, ...} integer id
> field in the task struct, that is copied on fork, and can be queried and
> manipulated from user space, in accordance with whatever rules you
> implement?
If a process belongs to several group of processes, an new integer in
the task_struct is not enough, you need a list or something like this.
If you're using a list you need to add function to manage this list in
the kernel but we don't want to add this kind of management inside the
kernel because with the fork connector we can keep it outside.
> When I look at the elsacct_process_copy() routine, which is called from
> fork, in your patch-2.6.8.1-elsa, I'm not sure what it does, but it sure
> looks like it could cause scaling and performance problems.
This patch is an old one with many kernel modifications that impacts the
Linux performance. That's why we thought about another solution where
all management is done by a user space daemon. Currently we're using the
fork connector.
> Does your user space daemon require to know about each task as it is
> forked, in near real time? Is it trying to do something with this
> accounting information while the tasks being accounted for are
> necessarily still alive?
I don't need real time. I just need to know which process forks during
the accounting period. The user space daemon provided by ELSA just keeps
a trace of parents and its children during a given period (generally
it's the accounting period). The analysis will be done later by another
application (also provided by ELSA) by using the trace of parents and
children plus the accounting trace.
> The main problems I was aware of with that classic accounting (which
> is probably what is now known as BSD accounting) are:
> ... [cut here] ...
> 2) An additional bank/job/aggregate/session/group/... id seems desired.
> I have yet to understand why this need be anything fancier than
> another integer field in the task struct.
We're trying to solve this one. I think that I answer to the integer
field problem. For the necessity of the per-group accounting, it can be
interesting to do accounting on a specific "task". For example if you
want to have accounting data for a compilation you can add the
corresponding shell in a group of processes and commands involved in the
compilation like gcc, cc, as, collect2, ... will be automatically added
in the same group and you will be able to get statistics about this
compilation.
> 3) Probably some more data items are worth collecting -- which could
> be placed in the outgoing compressed data stream, along with the
> existing records written on task exit. Over time, appropriate
> hooks should be proposed to collect such data as seems needed.
There is a discussion about this with Jay Lan to merge the CSA and BSD
accounting framework.
I don't know if there is some work around 1) and 4).
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Elsa-devel] Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 reference to symbol like 'cn_already_initialized' or 'cn_netlink_send'. That's why the fork_connector() must be enable if CONFIG_CONNECTOR and CONFIG_FORK_CONNECTOR are selected as builtin and not as a module. I agree that it's not very elegant... > > + cn_netlink_send(msg, 1); > > "1" here means that this message will be delivered to any group > which has it's first bit set(1, 3, and so on) in given socket queue. > I suspect it is not what you want. > By design connector's users should send messages to the group it was > registered with > (which is obtained from idx field of the struct cb_id), in your case it > is CN_IDX_FORK, > and connector userspace consumers should bind to the same group (idx > value). > It is of course not requirement, but a fair path(hmm, I can add more > strict checks into connector). > By setting 0 as second parameter for cn_netlink_send() you will force > connector's core > to select proper group for you. Yes but cn_netlink_send() is looking for a callback with the same idx. As I don't use any callback, found == 0 and I have an error "Failed to find multicast netlink group for callback[0xfeed.0xbeef]". So the good call is: cn_netlink_send(msg, CN_IDX_FORK); Thanks for your help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Elsa-devel] Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 reference to symbol like 'cn_already_initialized' or 'cn_netlink_send'. That's why the fork_connector() must be enable if CONFIG_CONNECTOR and CONFIG_FORK_CONNECTOR are selected as builtin and not as a module. I agree that it's not very elegant... + cn_netlink_send(msg, 1); 1 here means that this message will be delivered to any group which has it's first bit set(1, 3, and so on) in given socket queue. I suspect it is not what you want. By design connector's users should send messages to the group it was registered with (which is obtained from idx field of the struct cb_id), in your case it is CN_IDX_FORK, and connector userspace consumers should bind to the same group (idx value). It is of course not requirement, but a fair path(hmm, I can add more strict checks into connector). By setting 0 as second parameter for cn_netlink_send() you will force connector's core to select proper group for you. Yes but cn_netlink_send() is looking for a callback with the same idx. As I don't use any callback, found == 0 and I have an error Failed to find multicast netlink group for callback[0xfeed.0xbeef]. So the good call is: cn_netlink_send(msg, CN_IDX_FORK); Thanks for your help, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 a fork occurs and which processes are involved. I don't see how to
do this without a hook in the do_fork() routine...
How is what you need, for process grouping, any more complex than
another sort of {bank, job, aggregate, session, group, ...} integer id
field in the task struct, that is copied on fork, and can be queried and
manipulated from user space, in accordance with whatever rules you
implement?
If a process belongs to several group of processes, an new integer in
the task_struct is not enough, you need a list or something like this.
If you're using a list you need to add function to manage this list in
the kernel but we don't want to add this kind of management inside the
kernel because with the fork connector we can keep it outside.
When I look at the elsacct_process_copy() routine, which is called from
fork, in your patch-2.6.8.1-elsa, I'm not sure what it does, but it sure
looks like it could cause scaling and performance problems.
This patch is an old one with many kernel modifications that impacts the
Linux performance. That's why we thought about another solution where
all management is done by a user space daemon. Currently we're using the
fork connector.
Does your user space daemon require to know about each task as it is
forked, in near real time? Is it trying to do something with this
accounting information while the tasks being accounted for are
necessarily still alive?
I don't need real time. I just need to know which process forks during
the accounting period. The user space daemon provided by ELSA just keeps
a trace of parents and its children during a given period (generally
it's the accounting period). The analysis will be done later by another
application (also provided by ELSA) by using the trace of parents and
children plus the accounting trace.
The main problems I was aware of with that classic accounting (which
is probably what is now known as BSD accounting) are:
... [cut here] ...
2) An additional bank/job/aggregate/session/group/... id seems desired.
I have yet to understand why this need be anything fancier than
another integer field in the task struct.
We're trying to solve this one. I think that I answer to the integer
field problem. For the necessity of the per-group accounting, it can be
interesting to do accounting on a specific task. For example if you
want to have accounting data for a compilation you can add the
corresponding shell in a group of processes and commands involved in the
compilation like gcc, cc, as, collect2, ... will be automatically added
in the same group and you will be able to get statistics about this
compilation.
3) Probably some more data items are worth collecting -- which could
be placed in the outgoing compressed data stream, along with the
existing records written on task exit. Over time, appropriate
hooks should be proposed to collect such data as seems needed.
There is a discussion about this with Jay Lan to merge the CSA and BSD
accounting framework.
I don't know if there is some work around 1) and 4).
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 alerted when a fork occurs in the kernel. Whoaa ... you're saying that because you might have several groups a task could belong to at once, you'll use netlink to avoid managing lists in the kernel. Seems that you're spending thousands of instructions to save dozens. This is not a good trade off. I understand your point of view but I'm using netlink interface because it's already in the kernel so my choice is to use something that is already in the kernel instead of adding dozens of new instructions and also to do things in user space. The fork connector is here to move the management in the user space. Otherwise there is PAGG that manages group of processes in the kernel. To test performances, I tried to compile a kernel several times with and without the fork connector and here are the resource usage computed with the following command: time /bin/sh -c 'make O=/home/guill/build/k2610 oldconfig \ make O=/home/guill/build/k2610 bzImage \ make O=/home/guill/build/k2610 modules' between each test, the directory that contains object files was destroyed and a 'sync' was done. Results are: kernel without fork connector real : 8m17.042s 8m10.113s 8m08.597s 8m10.068s 8m08.930s user : 7m32.376s 7m35.985s 7m34.424s 7m34.221s 7m34.835s sys : 0m50.730s 0m51.139s 0m51.159s 0m51.406s 0m51.020s kernel with the fork connector real : 8m14.492s 8m08.656s 8m07.754s 8m08.002s 8m07.854s user : 7m31.664s 7m33.528s 7m33.625s 7m33.500s 7m33.822s sys : 0m50.651s 0m51.222s 0m51.102s 0m51.367s 0m50.894s kernel with the fork connector + application listens real : 8m08.596s 8m08.950s 8m08.899s 8m08.678s 8m08.987s user : 7m33.312s 7m33.898s 7m34.004s 7m33.285s 7m33.628s sys : 0m52.222s 0m52.013s 0m51.809s 0m52.361s 0m52.036s I also choose this implementation because Erich Focht wrote in the email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about the creation of processes sounds very useful for a lot of interesting stuff. So I thought about something that can be used by other application and with netlink, information is available to everyone. I can imagine several way cheaper ways to handle this. If the number of groups to which a task could belong has some small finite upper limit, like at most 5 groups, you could have 5 integer id's in the task struct instead of 1. If the number of elements in a particular group has a small upper bound, you could even replace the ints with bit fields. Or you could enumerate the different combinations of groups to which a task might belong, assign each such combination a unique integer, and keep that integer in the task struct. The enumeration could be done dynamically, only counting the particular combinations of group memberships that actually had use. This has the disadvantage that a particular combination, once enumerated, would have to stay around until the next boot - a potential memory leak. Probably not acceptable, unless the cost of storing a no longer used combination is nearly zero. The problem with those solutions is that we suppose that a process can belong to a finite number of task. I suppose that it can be true in practice. Or you could have a little 'jobids' struct that held a list and a reference counter, where the list held a particular combination of ids, and the reference counter tracked how many tasks referenced that jobids struct. Put a single pointer in the task struct to a jobids struct, and increment and decrement the reference counter in the jobids struct on fork and exit. Free it if the count goes to zero on exit. This solves the memory leak of the previous, with increased cost to the fork. Since we really do design these systems to stay up 'forever', this is perhaps the winner. Any time a particular task is added to, or removed from, a group, if the ref count of its jobids struct is one, then modify the id list attached to that jobids struct in place. If the ref count is more than one, copy the jobids struct and list to a new one, decrement the count in the old one, and modify the new one in place. Such list and counter manipulations are the daily stuff of kernel code. No need to avoid such. This solution is interesting. The problem is to know if a fork connector is useful for some other projects. As I said, one of my goal was to provide a way to alert user space application when a fork occurs in the kernel because I think that other applications need this kind of information. But if it is needed only by ELSA, you're right, a solution specific to our problem is clearly more efficient. Just
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 a netlink interface. It allows to several > > user space applications to be alerted when a fork occurs in the kernel. > > The main drawback is that even if nobody listens, a message is send. I > > don't know how to avoid that. I added an option (FORK_CONNECTOR) to > > enable the fork connector (or disable) when compiling the kernel. To > > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It > > has been tested on a 2.6.11-rc3-mm2 kernel with two user space > > applications connected. > > > > It is used by ELSA to manage group of processes in user space. In > > conjunction with a per-process accounting information, like BSD or CSA, > > ELSA provides a per-group of processes accounting. > > I think people will complain here... > ... [cut here] ... > I still think that lsm with all calls logging is the best way to > achieve this goal. I agree with you. My first implementation was with LSM but Chris Wright (I think it was him) notice that it's not the right framework (and it seems true). So I looked for another solution. I though about kobject but it was too "big" and finally, Greg KH spoke about connectors. It's small and efficient. > from the other side why only fork is monitored in this way? 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 a fork occurs and which processes are involved. I don't see how to do this without a hook in the do_fork() routine... Any ideas are welcome. Thank you Evgeniy for all your comments about the code, it helps and I will modify the patch. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A common layer for Accounting packages
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 accounting, > > CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke > > a routine in the common code which would then invoke those accounting > > packages that register to the acct_common to handle do_exit situation. > > This all seems to be heading in the wrong direction. Do we really want to > have lots of different system accounting packages all hooking into a > generic we-cant-decide-what-to-do-so-we-added-some-pointless-overhead > framework? > > Can't we get _one_ accounting system in there, get it right, avoid the > framework? Is it possible to just merge the BSD accounting and the CSA accounting by adding in the current BSD per-process accounting structure some missing fields like the mm integral provided by the CSA patch? ELSA is just a user of the accounting data. We need a hook in the do_fork() routine to manage group of processes, not to do accounting. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A common layer for Accounting packages
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 accounting, CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke a routine in the common code which would then invoke those accounting packages that register to the acct_common to handle do_exit situation. This all seems to be heading in the wrong direction. Do we really want to have lots of different system accounting packages all hooking into a generic we-cant-decide-what-to-do-so-we-added-some-pointless-overhead framework? Can't we get _one_ accounting system in there, get it right, avoid the framework? Is it possible to just merge the BSD accounting and the CSA accounting by adding in the current BSD per-process accounting structure some missing fields like the mm integral provided by the CSA patch? ELSA is just a user of the accounting data. We need a hook in the do_fork() routine to manage group of processes, not to do accounting. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
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 a netlink interface. It allows to several user space applications to be alerted when a fork occurs in the kernel. The main drawback is that even if nobody listens, a message is send. I don't know how to avoid that. I added an option (FORK_CONNECTOR) to enable the fork connector (or disable) when compiling the kernel. To work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It has been tested on a 2.6.11-rc3-mm2 kernel with two user space applications connected. It is used by ELSA to manage group of processes in user space. In conjunction with a per-process accounting information, like BSD or CSA, ELSA provides a per-group of processes accounting. I think people will complain here... ... [cut here] ... I still think that lsm with all calls logging is the best way to achieve this goal. I agree with you. My first implementation was with LSM but Chris Wright (I think it was him) notice that it's not the right framework (and it seems true). So I looked for another solution. I though about kobject but it was too big and finally, Greg KH spoke about connectors. It's small and efficient. from the other side why only fork is monitored in this way? 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 a fork occurs and which processes are involved. I don't see how to do this without a hook in the do_fork() routine... Any ideas are welcome. Thank you Evgeniy for all your comments about the code, it helps and I will modify the patch. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
