Re: RFC: design for new VM

From: Ingo Oeser (
Date: Thu Aug 03 2000 - 14:37:05 EST

On Thu, Aug 03, 2000 at 11:05:47AM -0700, Linus Torvalds wrote:
> As far as I can tell, the only advantage of multiple lists compared to the
> current one is to avoid overhead in walking extra pages, no?


> As far as I can tell, the above is _exactly_ equivalent to having one
> single list, and multiple "scan-points" on that list.


3 keywords:

   - reordering of the list breaks _all_ scanpoints
   - wraparound inside the scanner breaks ordering or it should
      store it's starting point globally
   - state transistions _require_ reordering, which will affect
      all scanners


   - scanners can only run exclusive (spinlock()ed) one at a
      point, if they can ever reorder the list, until the reach
      their temporally success or wrap point
   - scanners, that don't reorder the list have to be run under
      the guarantee, that the list will _never_ change until they
      reach their wrap point or succeed for now

Isn't this really bad for performance? It would imply a lot of
waiting, but I haven't measured this ;-)

With the multiple list approach we can skip pages easily and
avoid contention and stuck scanners (waiting for the list_lock to
become free).

Even your headache with the "purpose" of the lists might get
adressed, if you consider adding a queue in between for the
special state you need (like "dirty_but_not_really_list" ;-)).

The only wish _I_ have is having portal functions for _all_ state
transitions, which can be used as entry point for future
extensions which should continue adding portal functions for
their own transistions.

Practical example: *Nobody* was able to tell me, where we stop
   accessing a swapped out page (so it can be encrypted) and
   where we start accessing a swapped in page (so it has to be
   Would be no problem (nor a question ;-)) with portal functions
   for this important state transition.

PS: Maybe I didn't get your point with the "scan-points"


Ingo Oeser

Feel the power of the penguin - run linux@your.pc

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

This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:11 EST