linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ed Tomlinson <tomlins@cam.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-mm@kvack.org
Subject: Re: [RFC][PATCH] dcache and rmap
Date: Tue, 7 May 2002 07:41:52 -0400	[thread overview]
Message-ID: <200205070741.52896.tomlins@cam.org> (raw)
In-Reply-To: <20020507014414.GL15756@holomorphy.com>

On May 6, 2002 09:44 pm, William Lee Irwin III wrote

stuff omitted

> Well, I think there are three major design issues. The first is the
> magic number of 32 pages. This (compile-time!) tunable is almost
> guaranteed not to work for everyone. The second is that in order to

Yes.  I figured I would keep it simple for now.   This could be made a
proc tuneable or kswapd could be modifed to autotune this.

> address the issue you're actually concerned about, it seems you would
> have to present some method for caches to know their allocation requests
> would require evicting other useful data to satisfy; for instance,

This is an interesting idea.  Might be as simple as hooking into the slab.c
code and checking if the number of freepages is to small.  Then we could
increment a counter/flag (which counter/flag set at cache create time, 
associated with a 'driver'.  See below).  If this works it would be generic
too...

> evicting pagecache holding useful (but clean) user data to allocate
> dcache. Third, the distinguished position of the dcache is suspicious
> to me; I feel that a greater degree of generality is in order.

In two years I have never seen any cache other than the dcache/icache
cause the problem.  I short, yes its suspicious, but warented (here) by 
experience.

> In short, I don't think you went far enough. How do you feel about
> GFP_SPECULATIVE (a.k.a. GFP_DONT_TRY_TOO_HARD), cache priorities and
> cache shrinking drivers?

Think I will sprinkle slab.c with a printk or two to see if we detect when
it's allocations are eating other caches.  If this works we should be able to
let the vm know when to shrink the slab cache and to let it know which
caches need shrinking (ie shrink_caches becomes a 'driver' to shrink the
dcache/icache family.  kmem_cache_reap being the generic 'driver')

Thanks for the feedback and interesting idea,

Ed Tomlinson

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2002-05-07 11:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-06  1:17 Ed Tomlinson
2002-05-06  2:55 ` Martin J. Bligh
2002-05-06  7:54   ` Ed Tomlinson
2002-05-06 14:40     ` Martin J. Bligh
2002-05-06 15:12       ` Ed Tomlinson
2002-05-07  1:44 ` William Lee Irwin III
2002-05-07 11:41   ` Ed Tomlinson [this message]
2002-05-07 12:57     ` William Lee Irwin III
2002-05-07 14:10       ` Christoph Hellwig
2002-05-07 14:48         ` William Lee Irwin III
2002-05-13 11:07       ` Nikita Danilov
2002-05-13 11:50         ` Ed Tomlinson
2002-05-13 21:23           ` Andrew Morton
2002-05-07  1:01 Lever, Charles
2002-05-07  2:05 ` Martin J. Bligh

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=200205070741.52896.tomlins@cam.org \
    --to=tomlins@cam.org \
    --cc=linux-mm@kvack.org \
    --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