Re: excessive swap-in time

talon@xxxxxxxxxxxxxxxx (Michel Talon) writes:
phil-news-nospam@xxxxxxxx wrote:
| You can think of obvious ways to tweak this to make this one case
| perform better, but you can think of cases that are made worse by
| those same tweaks.

Something has to be forced back out to swap in a process that becomes
active again. The question is which pages to select. Those of processes
that are recently inactive would be what ultimately would be swapped out.
Might as well go straight to them directly, rather than the newly active
process fighting against its own pages.


Nothing new in this discussion. The Linux people have always been of the
advice that, "if there is not enough memory, buy some more",

If there is significant, continous paging activity on a system, a lot
of process will continously be blocked, waiting for disk I/O to
complete, before they can use some pages of memory, because their
previous contents need to be written to disk if the page was dirty and
the page content the process expects to be there needs to be read from
disk insofar the (physical) memory page was used by a different
process since the time process #0 accessed it last. In addition to
this, code execution of all processes will need to be wait for disk
I/O to complete frequently, because code pages which could otherwise
be cached in memory need to be read or reread from the binaries
containing them when the pages which held them last time they were
needed had been reused for something different in the
meantime. Possibly, the system needs to write the contents of some
dirty pages to disk before it can read the code into them. Disk-I/O is
slow, compared to memory accesses, hence, processes on a system whose
working set does not fit into (physical) memory run slow.

This is not 'some evil conspiracy of "the Linux people"' but a
physical, measurable phenomenon. The way to speed things up is to
EITHER ADD MORE GODDAMN MEMORY OR REDUCE THE F***ING MEMORY DEMANDS OF
THE SOFTWARE.

Was that loud enough to get past the dirt barrier inside your ears this
time?

while it is well known and demonstrated that a system can very well
function fine and dandy with a constant stream of paging to swap.

Believe it or not, but some (actually, quite a few) people are really
old enough to personally remember the time when this was the general
and not exceptional case.
.

Relevant Pages

  • Re: Page Cache writeback too slow, SSD/noop scheduler/ext2
    ... When memory gets low this will result in very irregular performance ... The wk_update function does not write enough dirty pages, ... This forced write fills the disk queue and starves read calls that MySQL ... the real problem is in the writeback algorithm ...
    (Linux-Kernel)
  • Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massi
    ... Especially with lots of memory, allowing 40% of that memory to be dirty is ... queueing, if you fill up the disk queue with a few dozen (depends on the ...
    (Linux-Kernel)
  • Proposed Assembler Commands
    ... ACM Automatically Clear Memory ... BKCRDR Backspace Card Reader ... BKSPD Backspace Disk ... EIAO Execute In Any Order ...
    (sci.electronics.design)
  • Re: Att. Alex Nichol -VM cont.
    ... I find documentation that says a 4kb page in memory is written to the hard ... manner that a 4kb memory page is equal to a 4kb cluster written on the disk". ... So where is the basis for saying since 4kb paging in memory that 4kb clusters ...
    (microsoft.public.windowsxp.general)
  • RE: Page Cache writeback too slow, SSD/noop scheduler/ext2
    ... When memory gets low this will result in very irregular performance drops. ... The wk_update function does not write enough dirty pages, ... This forced write fills the disk queue and starves read calls that MySQL is ... the real problem is in the writeback algorithm ...
    (Linux-Kernel)