From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Bas Westerbaan <bas.westerbaan@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Conveying memory pressure to userspace?
Date: Thu, 10 May 2007 18:54:39 -0700 [thread overview]
Message-ID: <4643CCDF.7060608@mbligh.org> (raw)
In-Reply-To: <6880bed30705101756nb5bd0c5s97935b97d07f846a@mail.gmail.com>
Bas Westerbaan wrote:
> Hello,
>
> Quite a lot of userspace applications cache. Firefox caches pages;
> mySQL caches queries; libc' free (like practically all other
> userspace allocators) won't directly return the first byte of memory
> freed, etc.
>
> These applications are unaware of memory pressure. While the kernel
> is trying its best to to free memory by for instance dropping,
> possibly more valuable caches, userspace is left blissfully unaware.
>
> Obviously this isn't a really big problem, given that we've still got
> swap to swap out those rarely used caches, except for when the caches
> aren't _that_ rarely used and of which the backing store (eg.
> precomputed values) might be faster than the disk to swap back the
> pages from.
>
> A solution would be to either
>
> a) let the application make the kernel aware of pages that, when in
> memory pressure, may be dropped. This would be tricky to implement
> for the userspace: it's hard to avoid an application to race into a
> dropped page. However, the kernel can directly free a page from
> userspace, which makes it use full when under real pressure. This in
> contrast to
> b) letting the application register itself with a cache share
> priority. The application (and other aware applications) would then
> be able to query how fair they are at the moment proportional to their
> cache share priority. Freeing would still be completely in their own
> hands.
>
>
> The only relevant related matter I could find were madvise and mincore.
>
> With madvise pages can be marked to be unnecessary and these should be
> swapped out earlier. With mincore one can determine whether pages are
> resident (not cached). This would make an existing alternative to
> solution a. However, this doesn't eliminate the writes to the swap
> and polling everytime before accessing a cache isn't really pretty.
>
> I did consider guessing the memory pressure by looking at
> /proc/meminfo, but I think it isn't that accurate.
The prev_priority field in the zoneinfo stuff is more useful for
memory pressure. I'm playing with making a blocking callback that
can wake someone up when this gets down to a certain priority level
(prio=12 => everything's rosy, prio=0 => we're in deep shit).
> Before hacking something together (and being uncertain about the
> thoroughness with which I searched for existing work, sorry), I would
> like your thoughts on this.
>
> Please CC me, I'm not in the list.
>
> Bas
>
next prev parent reply other threads:[~2007-05-11 1:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-11 0:56 Conveying memory pressure to userspace? Bas Westerbaan
2007-05-11 1:54 ` Martin J. Bligh [this message]
2007-05-11 10:00 ` Bas Westerbaan
2007-05-11 17:05 ` Christoph Lameter
2007-05-11 20:48 ` Paul Jackson
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=4643CCDF.7060608@mbligh.org \
--to=mbligh@mbligh.org \
--cc=bas.westerbaan@gmail.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 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.