public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Mike Fedyk <mfedyk@matchmail.com>
Cc: William Lee Irwin III <wli@holomorphy.com>, linux-kernel@vger.kernel.org
Subject: Re: Large slab cache in 2.6.1
Date: Sun, 22 Feb 2004 13:33:09 +1100	[thread overview]
Message-ID: <403814E5.3070106@cyberone.com.au> (raw)
In-Reply-To: <40380DE2.4030702@matchmail.com>



Mike Fedyk wrote:

> William Lee Irwin III wrote:
>
>> Mike Fedyk wrote:
>>
>>>> I have 1.5 GB of ram in this system that will be a Linux Terminal 
>>>> Server (but using Debian & VNC).  There's 600MB+ anonymous memory, 
>>>> 600MB+ slab cache, and 100MB page cache.  That's after turning off 
>>>> swap (it was 400MB into swap at the time).
>>>
>>
>>
>> On Sat, Feb 21, 2004 at 05:09:34PM -0800, Mike Fedyk wrote:
>>
>>> Here's my top slab users:
>>> dentry_cache      585455 763395    256   15    1 : tunables  120   
>>> 60 8 : slabdata  50893  50893      3
>>> ext3_inode_cache  686837 688135    512    7    1 : tunables   54   
>>> 27 8 : slabdata  98305  98305      0
>>> buffer_head        34095  78078     48   77    1 : tunables  120   
>>> 60 8 : slabdata   1014   1014      0
>>> vm_area_struct     42103  44602     64   58    1 : tunables  120   
>>> 60 8 : slabdata    769    769      0
>>> pte_chain          20964  43740    128   30    1 : tunables  120   
>>> 60 8 : slabdata   1458   1458      0
>>
>>
>>
>> Similar issue here; I ran out of filp's/whatever shortly after booting.
>
>
> So Nick Piggin's VM patches won't help with this?
>

Probably not.

The main thing they do is to try to be smarter about which active
mapped pages to evict. The slab shrinking balance is pretty well
unchanged.

However there is one path in try_to_free_pages that I've changed
to shrink the slab where it otherwise wouldn't. It is pretty
unlikely that would would be continually running into this path,
but testing is welcome, as always.

Stupid question: you didn't actually say what the problem is...
having 600MB slab cache and 400MB swap may not actually be a
problem provided the swap is not being used and the cache is.

I have an idea it might be worthwhile to try using inactive list
scanning as an input to slab pressure...

Nick


  parent reply	other threads:[~2004-02-22  2:39 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-22  0:50 Large slab cache in 2.6.1 Mike Fedyk
2004-02-22  1:09 ` Mike Fedyk
2004-02-22  1:20   ` William Lee Irwin III
2004-02-22  2:03     ` Mike Fedyk
2004-02-22  2:17       ` William Lee Irwin III
2004-02-22  2:38         ` Nick Piggin
2004-02-22  2:46           ` William Lee Irwin III
2004-02-22  2:40         ` Mike Fedyk
2004-02-22  2:58           ` Nick Piggin
2004-02-22  2:33       ` Nick Piggin [this message]
2004-02-22  2:46         ` Nick Piggin
2004-02-22  2:54           ` Nick Piggin
2004-02-22  2:36 ` Chris Wedgwood
2004-02-22  3:03   ` Linus Torvalds
2004-02-22  3:11     ` Chris Wedgwood
2004-02-22  3:28       ` Linus Torvalds
2004-02-22  3:29         ` Chris Wedgwood
2004-02-22  3:31         ` Chris Wedgwood
2004-02-22  4:01           ` Nick Piggin
2004-02-22  4:10             ` Nick Piggin
2004-02-22  4:30               ` Nick Piggin
2004-02-22  4:41                 ` Mike Fedyk
2004-02-22  5:37                   ` Nick Piggin
2004-02-22  5:44                     ` Chris Wedgwood
2004-02-22  5:52                       ` Nick Piggin
2004-02-22  5:50                     ` Mike Fedyk
2004-02-22  6:01                       ` Nick Piggin
2004-02-22  6:17                         ` Andrew Morton
2004-02-22  6:35                           ` Nick Piggin
2004-02-22  6:57                             ` Andrew Morton
2004-02-22  7:20                               ` Nick Piggin
2004-02-22  8:36                             ` Chris Wedgwood
2004-02-22  9:13                               ` Andrew Morton
2004-02-23  0:16                                 ` Nick Piggin
2004-02-23  0:26                                   ` Andrew Morton
2004-02-23  0:34                                     ` Nick Piggin
2004-02-23  0:46                                       ` Andrew Morton
2004-02-23  0:54                                         ` Nick Piggin
2004-02-23  1:00                                           ` Andrew Morton
2004-02-23  1:06                                             ` Nick Piggin
2004-02-22  6:45                         ` Mike Fedyk
2004-02-22  6:58                           ` Nick Piggin
2004-02-22  7:20                             ` Mike Fedyk
2004-02-22  6:09                 ` Andrew Morton
2004-02-22 17:05                   ` Linus Torvalds
2004-02-23  0:29                     ` Nick Piggin
2004-02-22  6:15         ` Andrew Morton
2004-02-22 16:08           ` Martin J. Bligh
2004-02-22 17:55             ` Jamie Lokier
2004-02-23  3:45               ` Mike Fedyk
2004-02-22 21:13             ` Dipankar Sarma
2004-02-22 14:03         ` Ed Tomlinson
2004-02-23  2:28           ` Mike Fedyk
2004-02-23  3:33             ` Ed Tomlinson
2004-02-22  3:21     ` Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2004-02-22 11:00 Manfred Spraul

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=403814E5.3070106@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=wli@holomorphy.com \
    /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