[lkml]   [2000]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: design for new VM
    On Thu, 3 Aug 2000, Linus Torvalds wrote:
    > On Thu, 3 Aug 2000, Rik van Riel wrote:
    > >
    > > The lists are not at all dependant on where the pages come
    > > from. The lists are dependant on the *page age*. This almost
    > > sounds like you didn't read my mail... ;(
    > I did read the email. And I understand that. And that's exactly
    > why I think a single-list is equivalent (because your lists
    > basically act simply as "caches" of the page age).

    If you add "with statistics about how many pages of age 0 there
    are" this is indeed the case.

    > > NO. We need different queues so waiting for pages to be flushed
    > > to disk doesn't screw up page aging of the other pages (the ones
    > > we absolutely do not want to evict from memory yet).
    > Go back. Read it. Realize that your "multiple queues" is nothing
    > more than "cached information". They do not change _behaviour_
    > at all. They only change the amount of CPU-time you need to
    > parse it.

    If the information is cached somewhere else, then this is indeed
    the case. My point is that we need to know how many pages with
    page->age==0 we have, so we can know if we need to scan memory
    and age more pages or if we should simply wait a bit until the
    currently old pages are flushed to disk and ready to be reused.

    > Basically, answer me this _simple_ question: what _behavioural_
    > differences do you claim multiple queues have? Ignore CPU usage
    > for now.
    > I'm claiming they are just a cache.
    > And you claim that the current MM cannot be balanced, but your
    > new one can.

    I agree that we could cache the information about how many pages
    of different ages and different dirty state we have in memory in
    a different way.

    We could have one single queue, as you wrote, and a number of
    counters. Basically we'd need a counter for the number of old
    (age==0) clean pages and one for the old dirty pages.

    Then we'd have multiple functions. Kflushd and kupdate would
    flush out the old dirty pages, __alloc_pages would walk the
    list to reclaim the old clean pages and we'd have a separate
    page aging function that only walks the list when we're short
    on free + inactive_dirty + inactive_clean pages.

    That would give us the same behaviour as the plan I wrote.

    What I fail to see is why this would be preferable to a code
    base where all the different pages are neatly separated and
    we don't have N+1 functions that are all scanning the same
    list, special-casing out each other's pages and searching
    the list for their own special pages...


    "What you're running that piece of shit Gnome?!?!"
    -- Miguel de Icaza, UKUUG 2000

    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:57    [W:0.034 / U:2.756 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site