Messages in this thread | | | Date | Sun, 10 May 2009 21:13:50 +0100 | From | Alan Cox <> | Subject | Re: [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
| |