![]() | |||||||||||||
Messages in this thread |
Magnus Damm wrote: > Unmapped patches - Use two LRU:s per zone. > > These patches break out the per-zone LRU into two separate LRU:s - one for > mapped pages and one for unmapped pages. The patches also introduce guarantee > support, which allows the user to set how many percent of all pages per node > that should be kept in memory for mapped or unmapped pages. This guarantee > makes it possible to adjust the VM behaviour depending on the workload. > > Reasons behind the LRU separation: > > - Avoid unnecessary page scanning. > The current VM implementation rotates mapped pages on the active list > until the number of mapped pages are high enough to start unmap and page out. > By using two LRU:s we can avoid this scanning and shrink/rotate unmapped > pages only, not touching mapped pages until the threshold is reached. > > - Make it possible to adjust the VM behaviour. > In some cases the user might want to guarantee that a certain amount of > pages should be kept in memory, overriding the standard behaviour. Separating > pages into mapped and unmapped LRU:s allows guarantee with low overhead. > > I've performed many tests on a Dual PIII machine while varying the amount of > RAM available. Kernel compiles on a 64MB configuration gets a small speedup, > but the impact on other configurations and workloads seems to be unaffected. > > Apply on top of 2.6.16-rc5. > > Comments? > I did something similar a while back which I called split active lists. I think it is a good idea in general and I did see fairly large speedups with heavy swapping kbuilds, but nobody else seemed to want it :P So you split the inactive list as well - that's going to be a bit of change in behaviour and I'm not sure whether you gain anything. I don't think PageMapped is a very good name for the flag. I test mapped lazily. Much better way to go IMO. I had further patches that got rid of reclaim_mapped completely while I was there. It is based on crazy metrics that basically completely change meaning if there are changes in the memory configuration of the system, or small changes in reclaim algorithms. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-10 04:58 [from the cache] ©2003-2008 | |||||||||||||