Messages in this thread |  | | Date | Fri, 21 Sep 2001 14:55:56 +0200 | From | Stephan von Krawczynski <> | Subject | Re: broken VM in 2.4.10-pre9 |
| |
On Fri, 21 Sep 2001 09:13:07 -0300 (BRST) Rik van Riel <riel@conectiva.com.br> wrote:
> On Fri, 21 Sep 2001, Stephan von Krawczynski wrote: > > > Shit, if I only were able to implement that. Can anybody help me to > > proove my point? > > Trying to implement your idea would probably pose a nice > counter-argument. Without measuring which pages are in > heavy use, how are you going to evict the right pages ?
Hi Rik,
The really beautiful thing about it is that you can divide it completely in two parts: 1) basic list handling, you obviously need the list itself and some atomic functions to queue/dequeue/requeue entries, possibly as well as get_next_freeable() for simplicity. The rest vm only uses this to work. 2) the management "plugins" where you can virtually do any check of heavy use or aging or buddy-finding or whatever comes to your mind and requeue accordingly. You may do that on every alloc (surely not nice), or on page hits, or on low-mem condition (like page_launder), or in a independant process (somehow like kswapd), whatever you tend to believe is the best performing way - feel free to find the killer-plugin :-).
BUT (and thats the real good point): (2) is completely independant in structure and processing from the basic mem-handling, because the only interaction is requeuing, which means as a first step (only experimental of course) you could just fill the list with addtail and shorten it on demand of free pages with remhead (hope my short-terms are understandable). This implements a _very_ simple aging based on only the age of the allocation and nothing else (FIFO). You can spend any time and brain in refining the strategy without ever touching the vm basics _and_ (because of the simple and clean interface between (1) and (2), you got no chance to screw things up (unless you do not drop entries in a bug-implementation)). No obvious need for patches or weird workarounds.
Your opinion?
Regards, Stephan
- 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/
|  |