On Wed 03-09-14 18:38:05, Ted Tso wrote: > On Thu, Sep 04, 2014 at 12:14:02AM +0200, Jan Kara wrote: > > > I didn't think we were allowed to reschedule or sleep while in > > > shrinker context? > > I believe we are allowed to sleep in the shrinker if appropriate gfp > > flags are set (__GFP_WAIT) and we enter extent cache shrinker only if > > __GFP_FS is set which guarantees __GFP_WAIT. > > I must be missing something. How is this guaranteed? > > I can see how we can determine what gfp_mask was used in the > allocation which triggered the shrinker callback, by checking > shrink->gfp_mask, but I don't see anything that guarantees that the > extent cache shrinker is only entered if __GFP_FS is set. > > I guess we could add something like: > > if ((shrink->gfp_mask & __GFP_WAIT) == 0) > return 0; > > to the beginning of ext4_es_scan(), but we're not doing that at the > moment. Ah, sorry. I was mistaken and thought we do check for __GFP_FS in ext4_es_scan() but we don't and we don't need to. But thinking about it again - if we're going to always scan at most nr_to_scan cache entries, there's probably no need to reduce s_es_lock latency by playing with spinlock_contended(), right? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
