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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:11 EST