lkml.org 
[lkml]   [2000]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: design for new VM
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

conclusions:

- 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
decrypted).

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"
approach.

Regards

Ingo Oeser
--
Feel the power of the penguin - run linux@your.pc
<esc>:x

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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