Messages in this thread | | | Date | Mon, 28 Feb 2005 15:25:51 +0100 | From | Thomas Graf <> | Subject | Re: [Lse-tech] Re: A common layer for Accounting packages |
| |
* 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |