On Friday 05 May 2006 10:49, Eric Dumazet wrote: > On a dual opteron box, I noticed high oprofile numbers in net/core/dst.c > , function dst_destroy(struct dst_entry * dst) > > It appears the smb_rmb() done at the begining of dst_destroy() is the > killer (this is a lfence machine instruction, that apparently is doing > a *lot* of things... may be IO related...) that is responsible for 80% > of the cpu time used by the whole function. > > I dont understand very much all variety of available barriers, and why > this smb_rmb() is used in dst_destroy(). > I missed the corresponding wmb that should be done somewhere in the dst > code. > > Do we have an alternative to smp_rmb() in the dst_destroy()/ kfree_skb() > context ?
Eliminating it probably wouldn't help very much - it just flushes the loads already in flight. If it didn't do that the next smp_rmb() would. I'm surprised there are that many though. Normally kernel code is spagetti enough that the CPU cannot speculate too many loads ahead. But are you 100% sure the cost is not in the lock decl ? That would make more sense. Perhaps profile for cache misses too and double check? -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
