On Thu, Sep 04, 2014 at 09:15:53AM +0200, Jan Kara wrote: > 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? I'm more generally worried contention on s_es_lock, since it's a file system-wide spinlock that is grabbed whenever we need to add or remove an inode from the es_list. So if someone were to try to run AIM7 benchmark on a large core count machine on an ext4 file system mounted on a ramdisk, this lock would likely show up. Now, this might not be a realistic scenario, but it's a common way to test for fs scalability without having a super-expensive RAID array, so it's quite common if you look at FAST papers over the last couple of years, for example.. So my thinking was that if we do run into contention, the shrinker thread should always yield, since if it gets slowed down slightly, there's no harm done. Hmmm.... OTOH, the extra cache line bounce could potentially be worse, so maybe it would be better to let the shrinker thread do its thing and then get out of there. - Ted -- 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
