[lkml]   [1998]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Strange interrupt behaviour
Gerard Roudier <> writes:

> A couple of months ago I tried to simulate the worst algorithm of memory
> management that worked as follow:
> 1 - Assume all the memory is busy.
> 2 - Free randomly 1 page at a time until N pages are available.
> I did'nt retreive the results, but I remember that even for N=2 results
> were quite bad (something > 25 % memory uselessly reaped).
[ .. ]
> How would you proceed for a similar problem in real life?
> Would'nt you try to be carefull to only try to victimize only things
> that have real chances to lead to the required result?

This leads to the obvious suggestion that we should be trying to
do something like:

Try and grab a pair; if that works we're done, get out of
here. else:

grab a page.
for the physical pages next to it, try and see if we can swap
them out. Ignore how busy they might be etc, just try
and do it.
if that fails, grab the next page and repeat.

The idea here is that if the page is really busy, what we're really
doing is moving them (they swapout and immediately back in; you can
obviously optimize the process a bit if you feel like it).

Provided that at least half our memory is swapable, this will always
succeed for 8K blocks (in general, provided at least (N-1)/N of our
memory is swapable, it's guarenteed to termate for allocating N

I suspect the real problem is that (last I looked: a _LONG_ time ago)
it's hard to go from a physical page number to what is actually using
it. Is this still the case?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:43    [W:0.091 / U:2.060 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site