I've got a test case which I intended to use to stress the VM a bit. It fills memory up with page cache a couple of times. It essentially runs 30 or so cp's in parallel.
98% of my CPU is system time, and 96% of _that_ is being spent on the spinlock in ext4_es_lru_add(). I think the LRU list head and its lock end up being *REALLY* hot cachelines and are *the* bottleneck on this test. Note that this is _before_ we go in to reclaim and actually start calling in to the shrinker. There is zero memory pressure in this test. I'm not sure the benefits of having a proper in-order LRU during reclaim outweigh such a drastic downside for the common case. Any thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
