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/
