From: Thomas G. <tg...@su...> - 2005-02-28 13:52:59
|
* jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > netlink broadcast or a wrapper around it. > Why even bother doing the check with netlink_has_listeners()? To implement the master enable/disable switch they want. The messages don't get send out anyway but why bother doing all the work if nothing will get send out in the end? It implements a well defined flag controlled by open/close on fds (thus handles dying applications) stating whether the whole code should be enabled or disabled. It is of course not needed to avoid sending unnecessary messages. |
From: jamal <ha...@cy...> - 2005-02-28 14:10:14
|
On Mon, 2005-02-28 at 08:53, Thomas Graf wrote: > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > netlink broadcast or a wrapper around it. > > Why even bother doing the check with netlink_has_listeners()? > > To implement the master enable/disable switch they want. The messages > don't get send out anyway but why bother doing all the work if nothing > will get send out in the end? It implements a well defined flag > controlled by open/close on fds (thus handles dying applications) > stating whether the whole code should be enabled or disabled. It is of > course not needed to avoid sending unnecessary messages. To justify writting the new code, I am assuming someone has actually sat down and in the minimal stuck their finger in the air and said "yes, there is definetely wind there". Which leadsto Marcello's question in other email: Theres some overhead. - Message needs to be built with skbs allocated (not the cn_xxx thing that seems to be invoked - I suspect that thing will build the skbs); - the netlink table needs to be locked -and searched and only then do you find theres nothing to send to. The point i was making is if you actually had to post this question, then you must be running into some problems of complexity ;-> which implies to me that the delta overhead maybe worth it compared to introducing the complexity or any new code. I wasnt involved in the discussion - I just woke up and saw the posting and was bored. So the justification for the optimization has probably been explained and it may be worth doing the check (but probably such check should go into whatever that cn_xxx is). cheers, jamal |
From: Thomas G. <tg...@su...> - 2005-02-28 14:25:41
|
* jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 > On Mon, 2005-02-28 at 08:53, Thomas Graf wrote: > > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > > > netlink broadcast or a wrapper around it. > > > Why even bother doing the check with netlink_has_listeners()? > > > > To implement the master enable/disable switch they want. The messages > > don't get send out anyway but why bother doing all the work if nothing > > will get send out in the end? It implements a well defined flag > > controlled by open/close on fds (thus handles dying applications) > > stating whether the whole code should be enabled or disabled. It is of > > course not needed to avoid sending unnecessary messages. > > To justify writting the new code, I am assuming someone has actually sat > down and in the minimal stuck their finger in the air > and said "yes, there is definetely wind there". I did, not for this problem though. The code this idea comes from sends batched events of skb passing points to userspace. Not every call invokes has_listeneres() but rather the kernel thread processing the ring buffer sending the events to userspaces does. The result is globally cached in a atomic_t making it possible to check for it at zero-cost and really saving time and effort. I have no clue wether it does make sense in this case I just pointed out how to do it properly at my point of view. > Which leadsto Marcello's question in other email: > Theres some overhead. > - Message needs to be built with skbs allocated (not the cn_xxx thing > that seems to be invoked - I suspect that thing will build the skbs); > - the netlink table needs to be locked > -and searched and only then do you find theres nothing to send to. > > The point i was making is if you actually had to post this question, > then you must be running into some problems of complexity ;-> > which implies to me that the delta overhead maybe worth it compared to > introducing the complexity or any new code. > I wasnt involved in the discussion - I just woke up and saw the posting > and was bored. So the justification for the optimization has probably > been explained and it may be worth doing the check (but probably such > check should go into whatever that cn_xxx is). I wasn't involved in the discussion either. Using rtmsg_ifinfo as example, the check should probably go in straight at the beginning _IFF_ rtmsg_ifinfo was subject to performance overhead which obviously isn't the case but just served as an example. |
From: jamal <ha...@cy...> - 2005-02-28 15:31:51
|
On Mon, 2005-02-28 at 09:25, Thomas Graf wrote: > * jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 [..] > > To justify writting the new code, I am assuming someone has actually sat > > down and in the minimal stuck their finger in the air > > and said "yes, there is definetely wind there". > > I did, not for this problem though. The code this idea comes from sends > batched events 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. I am gonna disapear for a while; hopefully the original posters have gathered some ideas from what we discussed. cheers, jamal |
From: Evgeniy P. <jo...@2k...> - 2005-02-28 15:53:50
|
On 28 Feb 2005 10:31:33 -0500 jamal <ha...@cy...> wrote: > On Mon, 2005-02-28 at 09:25, Thomas Graf wrote: > > * jamal <1109599803.2188.1014.camel@jzny.localdomain> 2005-02-28 09:10 > [..] > > > To justify writting the new code, I am assuming someone has actually sat > > > down and in the minimal stuck their finger in the air > > > and said "yes, there is definetely wind there". > > > > I did, not for this problem though. The code this idea comes from sends > > batched events > > 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. > > I am gonna disapear for a while; hopefully the original posters have > gathered some ideas from what we discussed. 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. > cheers, > jamal > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt |
From: Guillaume T. <gui...@bu...> - 2005-03-01 08:21:43
|
On Mon, 2005-02-28 at 19:17 +0300, Evgeniy Polyakov wrote: > On 28 Feb 2005 10:31:33 -0500 > jamal <ha...@cy...> 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 |
From: Marcelo T. <mar...@cy...> - 2005-02-28 14:17:13
|
On Mon, Feb 28, 2005 at 02:53:07PM +0100, Thomas Graf wrote: > * jamal <1109598010.2188.994.camel@jzny.localdomain> 2005-02-28 08:40 > > > > netlink broadcast or a wrapper around it. > > Why even bother doing the check with netlink_has_listeners()? > > To implement the master enable/disable switch they want. The messages > don't get send out anyway but why bother doing all the work if nothing > will get send out in the end? It implements a well defined flag > controlled by open/close on fds (thus handles dying applications) > stating whether the whole code should be enabled or disabled. Yep - this far from "reinventing the wheel". ;) > It is of course not needed to avoid sending unnecessary messages. Thats the goal, thanks. |
From: Marcelo T. <mar...@cy...> - 2005-02-28 13:53:47
|
I'm net ignorant, so just hit me with a cluebat if thats appropriate. On Mon, Feb 28, 2005 at 07:10:58AM -0500, jamal wrote: > > Havent seen the beginnings of this thread. But whatever you are trying > to do seems to suggest some complexity that you are trying to > workaround. What was wrong with just going ahead and just always > invoking your netlink_send()? What overhead does the netlink_send() impose if there are no listeners? Sure, it wont go anywhere, but the message will have to be assembled and sent anyway. Correct? The way things are now, its necessary to make the decision to invoke or not netlink_send() due to the supposed overhead. Thats what Guillaume is doing, and thats what will have to be done whenever one wants to send information through netlink from performance critical paths. Can't the assembly/etc overhead associated with netlink_send() be avoided earlier, approaching zero-cost ? Being able to get rid of the decision to invoke or not the sendmsg would be nice. TIA > If there are nobody in user space (or > kernel) listening, it wont go anywhere. > > cheers, > jamal > > On Mon, 2005-02-28 at 02:39, Andrew Morton wrote: > > Guillaume Thouvenin <gui...@bu...> wrote: > > > > > > Ok the protocol is maybe too "basic" but with this mechanism the user > > > space application that uses the fork connector can start and stop the > > > send of messages. This implementation needs somme improvements because > > > currently, if two 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. > > > > Yes. But this problem can be solved in userspace, with a little library > > function and a bit of locking. > > > > IOW: use the library to enable/disable the fork connector rather than > > directly doing syscalls. > > > > It has the problem that if a client of that library crashes, the counter > > gets out of whack, but really, it's not all _that_ important, and to handle > > this properly in-kernel each client would need an open fd against some > > object so we can do the close-on-exit thing properly. You'd need to create > > a separate netlink socket for the purpose. |
From: Paul J. <pj...@sg...> - 2005-03-01 20:41:41
|
Jamal wrote: > What was wrong with just going ahead and just always > invoking your netlink_send()? I think the hope was to reduce the cost of the accounting hook in fork to "next-to-zero" if accounting is not being used on that system. See Andrew's query earlier: > b) they are next-to-zero cost if something is listening on the netlink > socket but no accounting daemon is running. Presumably sending an ignored packet costs something, quite possibly more than "next-to-zero". -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373, 1.925.600.0401 |