All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Bueno <joseph.bueno@trader.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: VM balancing problems under 2.4.2-ac1
Date: Sat, 24 Feb 2001 11:33:28 +0100	[thread overview]
Message-ID: <3A978DF8.FB1890E@trader.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0102232120531.8568-100000@localhost.localdomain>

Rik van Riel a écrit :
> 
> On 23 Feb 2001, Adam Sampson wrote:
> 
> > The VM balancing updates in the recent ac kernels seem to have caused
> > some interesting performance problems on my desktop machine. I've got
> > 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large
> > amounts of it for buffers and cache while pushing stuff out to
> > swap. This means that Mozilla, for instance, runs significantly worse
> > than under 2.4.0, since bits of it are being swapped in and out.
> 
> This is a known problem which I'll fix as soon as I have a
> solution.
> 
> The problem is that we still have no good way to balance
> how much memory we take from the cache and how much memory
> we take from processes.
> 
> This means that for some workloads we'll be evicting too
> much cache while for other workloads we'll be evicting too
> much process pages...
> 
> If anybody as a good idea to make this code auto-balancing,
> please let me know.
> 
> regards,
> 
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
>                 http://www.surriel.com/
> http://www.conectiva.com/       http://distro.conectiva.com.br/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Hi Rik,

I understand that auto-balancing code that deals with all
situations is very hard to design; so let me share my experience
on other Unix systems (from a user/administrator point of view):

I have used Unix systems (mainly HPUX) for several years as personal
workstations or servers and buffer cache usage were very differents:

On workstations, you are mainly looking for fast interactive response
time and  you want to dedicate as much memory as possible to running
processes so limiting buffer cache to 10% of physical memory (these
workstations had typically 32 - 64 Mb of RAM) was good.

On file servers, interactive response time is much less important than
file/network througput. In this case, having 80% of RAM used for buffer
cache is good and you may even want to not let it go below 50% even if
it slows down some batch processes.

Both cases were easily handled by 2 HPUX kernel tunable parameters that
defined minimum and maximum number of pages that could be used by the
buffer cache.
This could be implemented on Linux via /proc. I know it is already done
for minimum limit (in 2.2, I have no experience with 2.4 yet).
I have found some situations where not being able to force a maximum
limit was a problem.

You could argue that with a good load balancing algorithm user
defined limits are useless. Believe me, my experience on HPUX
workstations showed that lowering its max. limit from 50% (default
value) to 10% turned some sluggish machines into speed daemons !

Just my 0.02$
Hope this helps
--
Joseph Bueno

  reply	other threads:[~2001-02-24 10:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23 20:00 VM balancing problems under 2.4.2-ac1 Adam Sampson
2001-02-24  2:22 ` Rik van Riel
2001-02-24 10:33   ` Joseph Bueno [this message]
2001-02-24 14:37     ` Rik van Riel
2001-02-26 16:33   ` Mike Galbraith
2001-03-03  0:03   ` Adrian Bunk
2001-03-04 17:26     ` Ingo Oeser
2001-03-05  7:05       ` Mike Galbraith
  -- strict thread matches above, loose matches on Subject: below --
2001-02-24  8:12 Benjamin Redelings I
2001-02-24 14:51 ` Rik van Riel

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=3A978DF8.FB1890E@trader.com \
    --to=joseph.bueno@trader.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.