[lkml]   [1996]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bugs and wishes in memory management area

In, Mark Hemment <> wrote:

>I'm not a fan of swapping out an entire process (is this what you mean?)
>It adds a lot of extra problems into the kernel (and hence more code),
>espically to the scheduler. While I hate to suggest someone spends
>money, if your system is thrashing the disk because of paging-out then
>you really should consider a few extra megas.

Depending on your application, "a few extra megs" won't cut it. Imagine
a scenario where two processes are competing for memory, both of which
are doing large matrix multiplications. This means pessimized access
patterns for anything resembling LRU. You will have to run completetly
within core to get anything resembling good performance.

This could possibly be done with a user-level daemon, which locks its
executable pages in memory (for good reason :-) and periodically
looks around for something to do. This daemon could send SIGSTOP
signals to processes it thinks should block for some time. The normal
paging code could take care of the rest.

Which processes should eligible for swapping? Basically, anything which
consumes large amounts of memory (in-core memory plus buffer cache), and
which is currently blocking on a 'fast' operation (i.e. a read) or is
ready to run or running.

Is there a way to monitor buffer cache usage by a process? Is there
a good way to get at the recent idle percentage, except by looking
at the current processes (which is not a very good idea, since they
may have exited in the meantime)?

 \ /
  Last update: 2005-03-22 13:38    [W:0.112 / U:7.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site