On Fri, Oct 01, 2010 at 05:18:03PM +0200, Benny Halevy wrote: > On 2010-10-01 16:50, J. Bruce Fields wrote: > > On Thu, Sep 30, 2010 at 08:47:46PM +0200, Benny Halevy wrote: > >> The existing code adjusted it based on the worst case scenario for the returned > >> bitmap and the best case scenario for the supported attrs attribute. > > > > Looks fine, thanks. Mind if I just ditch the unlikely()s? I know, > > they've been there for a while, but I'm just skeptical of their value on > > anything but the most unbelievably hot optimized-to-death code paths. > > Well, they don't bother me so I don't the value of ditching them either :) For me it's an infinitessimal optimization versus a very minor improvement in readability. Admittedly my scales of judgement may not be fine enough to correctly balance such small quantities.... Anyway, applied without annotations; thanks. --b. > > They're supposed to help branch prediction thus optimizing the common > code paths on the expense of the unlikely path but I too didn't measure > their affect. > > Bottom line is that I don't have and strong reservations either for or > against them in this case :) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html