[lkml]   [2001]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectLinux VM design
    Hi VM folks,

    I'd like to understand Linux VM but there's not much in
    Documentation/vm/* on the subject. I understand that with current
    frantic development pace it is hard to maintain such docs.

    However, with only a handful of people really understading how VM
    works we risk ending in a situation when nobody will know how to fix
    it (does recent Andrea's VM rewrite just replaced large part of hardly
    maintenable, not-quite-right VM in 2.4.10?)

    When I have a stalled problem to solve, I sometimes catch
    unsuspecting victim and start explainig what I am trying to do and
    how I'm doing that. Often, in the middle of my explanation, I realize
    myself what I did wrong. There is an old teacher's joke:
    "My pupils are dumb! I explained them this theme once, then twice, I
    finally myself understood it, and they still don't".
    Since we reached some kind of stability with 2.4, maybe
    Andrea, Rik and whoever else is considering himself VM geek
    would tell us not-so-clever lkml readers how VM works and put it in
    vm-2.4andrea, vm-2.4rik or whatever in Doc/vm/*,
    I will be unbelievably happy. Matt Dillon's post belongs there too.

    I have an example how I would describe VM if I knew anything about it.
    I am putting it in the zip attachment just to reduce number of
    people laughing on how stupid I am :-). Most lkml readers won't open
    it, I hope :-).

    If VM geeks are disagreeing with each other on some VM inner workings,
    they can describe their views in those separate files, giving readers
    ability to compare their VM designs. Maybe these files will evolve in
    VM FAQs.

    Saturday, September 22, 2001, 2:01:02 PM,
    Daniel Phillips <> wrote:
    DP> The arguments in support of aging over LRU that I'm aware of are:

    DP> - incrementing an age is more efficient than resetting several LRU list links
    DP> - also captures some frequency-of-use information

    Of what use this info can be? If one page is accessed 100 times/second
    and other one once in 10 seconds, they both have to stay in RAM.
    VM should take 'time since last access' into account whan deciding
    which page to swap out, not how often it was referenced.

    DP> - it can be implemented in hardware (not that that matters much)
    DP> - allows more scope for tuning/balancing (and also rope to hang oneself)

    DP> The big problem with aging is that unless it's entirely correctly balanced its
    DP> just not going to work very well. To balance it well requires knowing a lot
    DP> about rates of list scanning and so on. Matt Dillon perfected this art in BSD,
    DP> but we never did, being preoccupied with things like just getting the mm
    DP> scanners to activate when required, and sorting out our special complexities
    DP> like zones and highmem buffers. Probably another few months of working on it
    DP> would let us get past the remaining structural problems and actually start
    DP> tuning it, but we've already made people wait way too long for a stable 2.4.
    DP> A more robust strategy makes a lot of sense right now. We can still play with
    DP> stronger magic in 2.5, and of course Rik's aging strategy will continue to be
    DP> developed in Alan's tree while Andrea's is still going through the test of
    DP> fire.
    DP> </musings>

    DP> I'll keep reading Andrea's code and maybe I'll be able to shed some more light
    DP> on the algorithms he's using, since he doesn't seem to be in a big hurry to
    DP> do that himself. (Hi Andrea ;-)

    DP> --
    DP> Daniel
    DP> -
    DP> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    DP> the body of a message to
    DP> More majordomo info at
    DP> Please read the FAQ at

    Best regards, VDA[unhandled content-type:application/x-zip-compressed]
     \ /
      Last update: 2005-03-22 13:03    [W:0.027 / U:40.700 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site