Re: [2.6.16 PATCH] Filessytem Events Reporter V2

[Evgeniy Polyakov]

On Fri, Apr 07, 2006 at 11:47:16PM +0400, Evgeniy Polyakov (johnpol@xxxxxxxxxxx) wrote:
> On Fri, Apr 07, 2006 at 11:14:27PM +0800, Yi Yang (yang.y.yi@xxxxxxxxx) wrote:
> > Evgeniy Polyakov ??????:
> > >On Fri, Apr 07, 2006 at 06:03:04PM +0800, Yi Yang (yang.y.yi@xxxxxxxxx) 
> > >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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/