lkml.org 
[lkml]   [2009]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -mm] vmscan: make mapped executable pages the first class citizen
    > > Not only can it be abused but some systems such as java have large
    > > PROT_EXEC mapped environments, as do many other JIT based languages.
    >
    > On the file LRU side, or on the anon LRU side?

    Generally anonymous so it would indeed be ok.

    > > I still think the focus is on the wrong thing. We shouldn't be trying to
    > > micro-optimise page replacement guesswork - we should be macro-optimising
    > > the resulting I/O performance.
    >
    > Any ideas on how to achieve that? :)

    I know - vm is hard, and page out consists of making the best wrong
    decision without having the facts.

    Make your swap decisions depend upon I/O load on storage devices. Make
    your paging decisions based upon writing and reading large contiguous
    chunks (512K costs the same as 8K pretty much) - but you already know
    that .

    Historically BSD tackled some of this by actually swapping processes out
    once pressure got very high - because even way back it actually became
    cheaper at some point than spewing randomness at the disk drive. Plus it
    also avoids the death by thrashing problem. Possibly however that means
    the chunk size should relate to the paging rate ?

    I get to watch what comes down the pipe from the vm, and it's not pretty,
    especially when todays disk drive is more like swapping to a tape loop. I
    can see how to fix anonymous page out (log structured swap) but I'm not
    sure what that would do to anonymous page-in even with a cleaner.

    At the block level it may be worth having a look what is going on in more
    detail - the bigger queues and I/O sizes on modern disks (plus the
    cache flushimng) also mean that the amount of time it can take a command
    to the head and back to the OS has probably jumped a lot with newer SATA
    devices - even if the block layer is getting them queued at the head of
    the queue and promptly. I can give a disk 15 seconds of work quite easily
    and possibly stuffing the disk stupid isn't the right algorithm when
    paging is considered.

    rpm -e gnome* and Arjan's ioprio hacks seem to fix my box but thats not a
    general useful approach. I need to re-test the ioprio hacks with a
    current kernel and see if the other I/O changes have helped.

    Alan


    \
     
     \ /
      Last update: 2009-05-10 22:19    [W:4.201 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site