Hello,
Marcelo Tosatti wrote: > Yep, the netlink people should be able to help - they known what would be > required for not sending messages in case there is no listener registered. > > Maybe its already possible? I have never used netlink myself.
If we notify the fork/exec/exit-events to user-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.
>>And, why can't netlink packets send always? >>If there are fork/exec/exit hooks, and they call CSA or other >>process-grouping modules, >>then those modules will decide whether packets for interaction with the >>daemon should be >>sent or not. > > > The netlink data will be sent to userspace at fork/exec/exit hooks - one wants > to avoid that if there are no listeners, so setups which dont want to run the > accounting daemon dont pay the cost of building and sending the information > through netlink. > > Thats what Andrew asked for if I understand correctly.
Does it mean "netlink packets shouled be sent to userspace unconditionally." ? I have advocated steadfastly that fork/exec/exit hooks is necessary to support process-grouping and to account per process-grouping. It intend to be decided whether packets should be sent or not by hooked functions, in my understanding. Is it also one of the implementations whether using netlink-socket or not ?
>>In most considerable case, CSA's kernel-loadable-module using such hooks >>will not be loaded >>when no accounting daemon is running. Adversely, this module must be loaded >>when accounting >>daemon needs CSA's netlink packets. >>Thus, it is only necessary to refer flag valiable and to execute >>conditional-jump >>when no-accounting daemon is running. > > > That would be one hack, although it is uglier than the pure netlink > selection.
No, I can't agree this opinion. It means netlink-packets will be sent unconditionally when fork/exec/exit occur. Nobady can decide which packet is sent user-space, I think.
In addition, the definition of process grouping is lightweight in many cases. For example, CpuSet can define own process-group by one increment-operation.
I think it's not impossible to implement it in userspace, but it's not reasonable. An implementation as a kernel loadable module is reasonable and enough tiny.
>>In my estimation, we must pay additional cost for an increment-operation, >>an decrement-op, >>an comparison-op and an conditional jump-op. It's enough lightweight, I >>think. >> >>For example: >>If CSA's module isn't loaded, 'privates_for_grouping' will be empty. >> >>inline int on_fork_hook(task_struct *parent, task_struct *newtask){ >> rcu_read_lock(); >> if( !list_empty(&parent->privates_for_grouping) ){ >> ..<Calling to any process grouping module>..; >> } >> rcu_read_unlock(); >>} > > > Andrew has been talking about sending data over netlink to implement the > accounting at userspace, so this piece of code is out of the game, no?
Indeed, I'm not opposed to implement the accounting in userspace and using netlink-socket for kernel-daemon communication. But definition of process-grouping based on any grouping policy should be done in kernel space at reasonability viewpoint.
Thanks. -- Linux Promotion Center, NEC KaiGai Kohei <[EMAIL PROTECTED]> - 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/
