Messages in this thread | | | Date | Sat, 8 Apr 2006 00:27:04 +0400 | From | Evgeniy Polyakov <> | Subject | Re: [2.6.16 PATCH] Filessytem Events Reporter V2 |
| |
On Fri, Apr 07, 2006 at 11:47:16PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote: > On Fri, Apr 07, 2006 at 11:14:27PM +0800, Yi Yang (yang.y.yi@gmail.com) wrote: > > Evgeniy Polyakov ??????: > > >On Fri, Apr 07, 2006 at 06:03:04PM +0800, Yi Yang (yang.y.yi@gmail.com) > > >wrote: > > > > > >>>>Can you explain why there is such a big difference between > > >>>>netlink_unicast and netlink_broadcast? > > >>>> > > >>>> > > >>>Netlink broadcast clones skbs, while unicasting requires the whole new > > >>>one. > > >>> > > >>> > > >>No, I also use clone to send skb, so they should have the same overhead. > > >> > > > > > >I missed that. > > >After rereading fsevent_send_to_process() I do not see how original skb > > >is freed though. > > > > > I'm considering how to free it, because cloned skbs share data with > > original skb, so this case is special, > > I try to clarify the logic of kfree_skb. > > Just call kfree_skb() after fsevent_send_to_process() or at the very > end of this function. If unicast delivering fails you also need to free cloned skb.
For clarification: I mean if any error happens before netlink_unicast() call, you need to free skb. If netlink_unicast() is called, it will take care of skb in any case.
> > > > > >>>>>Btw, you need some rebalancing of the per-cpu queues, probably in > > >>>>>keventd, since CPUs can go offline and your messages will stuck foreve > > >>>>>there. > > >>>>> > > >>>>> > > >>>>> > > >>>>Does keventd not do it? if so, keventd should be modified. > > >>>> > > >>>> > > >>>How does keventd know about your own structures? > > >>>You have an per-cpu object, but your keventd function gets object > > >>> > > >>>from running cpu, not from any other cpus. > > >> > > > > > > > > -- > Evgeniy Polyakov
-- Evgeniy Polyakov - 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/
| |