On Fri, Sep 13, 2013 at 09:18:03PM +0100, Al Viro wrote: > On Fri, Sep 13, 2013 at 09:00:00PM +0100, Al Viro wrote: > > > - d_lru_shrink_move: move from the "global" lru list to a private shrinker list > > > - d_shrink_add/del: fairly obvious. > > > > > > And then "denty_lru_add/del" that actually take the current state into > > > account and do the right thing. Those we had before, I'm just > > > explaining the difference from the low-level operations that have > > > fixed "from this state to that" semantics > > > > Looks sane; FWIW, the variant I'm playing with uses two independent > > flags for "shrinker" and "per-sb", but AFAICS that doesn't yield better > > code. > > Actually, it does yield slightly better code... Look - if you take your > patch and replace LRU_LIST | SHRINK_LIST combination with bare SHRINK_LIST > (which can't occur right now). Then all transitions turn into flipping ^^^ > a single bit, Obviously not *and* lru->shrink is common ;-/ Anyway, any benefit from microoptimizing that will drown in noise, so... nevermind that idea. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
