Re: [PATCH 00/03] Unmapped: Separate unmapped and mapped pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux