> Where would you like to call it with argument 0?
> As we (David Miller and myself) explained a few times already, the nice
> thing about page table cache is that it requires now locking, so it is
> pretty fast. So you have to call it from the same CPU the cache is on, which
> is usually not the case with try_to_free_pages etc.
Hi Jakub,
I've worked out a scheme to allow kswapd to trim the pgt cache without requiring any locking. It works by having the vm system
trim its own CPU's cache by calling check_pgt_cache(0), and then setting a per-CPU trim flag so that the idle tasks for the other
CPUs will temporarily call check_pgt_cache() with 0 instead of pgt_cache_water[0]. Then once the cache size hits 0 on a
particular CPU, it clears the trim flag and goes back to using pgt_cache_water[0].
This lets kswapd gradually drain its own pgt cache and get the memory from the other CPUs whenever the idle tasks next run. There
are no locking problems because the work is always done on the CPU owning the cache.
> What could be possible and could help would be to set the pgt_cache_water
> marks defaults according to the actual amount of memory detected...
Possibly the cache size should scale not just with memory size, but with the expected frequency of task forking. A system with
modest memory but spawning many tasks might benefit from a larger cache.
Once kswapd is able to access the pgt cache pages, people will be able to configure larger pgt caches knowing that the memory is
accessible when they need it.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html