On 09/12/2013 07:16 AM, Christoph Lameter wrote: > On Wed, 11 Sep 2013, Dave Hansen wrote: > >> 3. We want ->high to approximate the size of the cache which is >> private to a given cpu. But, that's complicated by the L3 caches >> and hyperthreading today. > > well lets keep it well below that. There are other caches (slab related > f.e.) that are also in constant use. At the moment, we've got a on-size-fits-all approach. If you have more than 512MB of RAM in a zone, you get the high=186(744kb)/batch=31(124kb) behavior. On my laptop, I've got 3500kB of L2+L3 for 4 logical cpus, or ~875kB/cpu. According to what you're saying, the high mark is probably a _bit_ too high. On a modern server CPU, the caches are about double that (per cpu). >> I'll take one of my big systems and run it with some various ->high >> settings and see if it makes any difference. > > Do you actually see contention issues on the locks? I think we have a > tendency to batch too much in too many caches. Nope. This all came out of me wondering what that /=4 did. It's pretty clear that we've diverged a bit from what the original intent of the code was. We need to at _least_ fix the comments up. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>