mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "M. Edward Borasky" <znmeb@aracnet.com>
To: "Art Hays" <art@lsr.nei.nih.gov>, <linux-kernel@vger.kernel.org>
Subject: RE: kswapd etc hogging machine
Date: Wed, 2 Jan 2002 20:01:29 -0800	[thread overview]
Message-ID: <HBEHIIBBKKNOBLMPKCBBAECPEFAA.znmeb@aracnet.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0201022214230.8413-100000@lsr-linux>

Well known, yes -- simple solution, not yet :)). This problem has been
kicking around in one form or another for *months*, and although partial
solutions have made their way into more recent kernels, someone reports
issues of this nature on a more or less daily basis. What is happening is
that Linux sees nothing better to do with free memory, so it fills it up
with data from I/O into the page cache. Then when something comes along that
wants memory, the system goes into conniption fits trying to reclaim the
memory from the page cache and give it to the process that wants it.

There were a whole bunch of tuning parameters in the VM in 2.2 that got
dropped in 2.4; maybe re-instating some of them and returning them to their
rightful owner, the system administrator, would solve this problem once and
for all. But for some reason, those who control Linux have decided that this
is "a bug in the VM" and pursued fixes in code and the associated logic
rather than give us sysadmins what I believe is rightfully ours. I request
such tuning parameters at least once a week here, and get ignored. I'll keep
asking until I know enough about the code to put them in myself, assuming no
one has broken down and admitted that someone who's been performance tuning
operating systems since 1974 just might know what he's talking about :)).

Anyone else want to share my soapbox??? :))
--
M. Edward Borasky

znmeb@borasky-research.net
http://www.borasky-research.net


  reply	other threads:[~2002-01-03  4:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-03  3:33 Art Hays
2002-01-03  4:01 ` M. Edward Borasky [this message]
2002-01-03  4:13   ` Dave Jones
2002-01-03  5:15   ` Andrew Morton
2002-01-03  5:48     ` Daniel Phillips
2002-01-03  5:54       ` Jeffrey W. Baker
2002-01-03 12:32     ` Alan Cox
2002-01-03 16:51       ` Rik van Riel
2002-01-03 17:27       ` Stephan von Krawczynski
2002-01-03 17:32         ` Rik van Riel
2002-01-03 23:42           ` Stephan von Krawczynski
2002-01-03 18:59       ` Andrew Morton
2002-01-04  7:06       ` Art Hays
2002-01-03 12:37 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HBEHIIBBKKNOBLMPKCBBAECPEFAA.znmeb@aracnet.com \
    --to=znmeb@aracnet.com \
    --cc=art@lsr.nei.nih.gov \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®