public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Tomlinson <tomlins@cam.org>
To: "Kingsley G. Morse Jr." <change@nas.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: What obvious symptoms addressed by the slablru patch?
Date: Sat, 10 Aug 2002 08:06:01 -0400	[thread overview]
Message-ID: <200208100806.01828.tomlins@cam.org> (raw)
In-Reply-To: <20020809192530.A7098@debian1.loaner.com>

HI Kingsley

You wrote:
>
>     If you are having slab memory problems or
>     dcache/icache get too large and seen not to be
>     pruned 'correctly' - This patch may well help.
>
> and
>
>     Feedback very welcome
>
> Can you elaborate on what:
>
>     slab memory problems and
>
>     dcache/icache
>
>         getting too large and
>         not being pruned 'correctly'
>
> look like to an end user?

Without slablru on a lightly loaded box you would see memory 'disappear'
ie. vmstat would show the free/buf/cache numbers decreasing.   If you
then looked at /proc/slabinfo you would see some caches (usually inode
and dentry) using lots of memory.  This memory eventually will get reclaimed
when we get vm pressure.  With out slablru this pressure comes too late
and is often caused by slab caches instead of real world loads...

What slablru does basicly is sync the shrinking of slab caches with the
rest of the vm.  So if you allocate lots of slab pages (like during an updatedb
run) the vm takes this into account and even with low vm pressure starts
trimming caches.  This means that, while slab caches can still get large, the
vm will trim them at the same rate it does other pages.  It no longer waits
until too long to do so.

One small detail in slablru.  There are currently two types of slab caches.
Those that free slabs directly and those that age their slabs before freeing
them.  The dcache (dentries) and inode caches age their members.  This
also contributed to the above problem.  The stock kernel ages and 
shrinks at the same time.  slablru factors out aging and shrinking.  This
helps keep these caches using their fair share (which can be large) of
the systems resources.

Ed Tomlinson


           reply	other threads:[~2002-08-10 12:02 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20020809192530.A7098@debian1.loaner.com>]

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=200208100806.01828.tomlins@cam.org \
    --to=tomlins@cam.org \
    --cc=change@nas.com \
    --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