From: "Emery Berger" <emery@cs.umass.edu>
To: Rik van Riel <riel@redhat.com>, Yi Feng <yifeng@cs.umass.edu>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@osdl.org>,
Matthew Hertz <hertzm@canisius.edu>
Subject: RE: [patch] vmsig: notify user applications of virtual memory events via real-time signals
Date: Tue, 22 Nov 2005 16:53:22 -0500 [thread overview]
Message-ID: <B061F5ED2860D9439AE34EE5C141938C090CDE@zor.ads.cs.umass.edu> (raw)
> That seems pretty high overhead. I wonder if it wouldn't work
> similarly well for the kernel to simply notify the registrered
> apps that memory is running low and they should garbage collect
> _something_, without caring which pages.
Actually, it's quite important that the application know exactly which
page is being evicted, in order that it be "bookmarked". We found that
this particular aspect of the garbage collection algorithm was crucial
(it's in the paper).
Best,
-- emery
--
Emery Berger
Assistant Professor
Dept. of Computer Science
University of Massachusetts, Amherst
www.cs.umass.edu/~emery
> -----Original Message-----
> From: Rik van Riel [mailto:riel@redhat.com]
> Sent: Tuesday, November 22, 2005 4:45 PM
> To: Yi Feng
> Cc: linux-mm@kvack.org; 'Andrew Morton'; Emery Berger; 'Matthew Hertz'
> Subject: Re: [patch] vmsig: notify user applications of virtual memory
> events via real-time signals
>
> On Tue, 22 Nov 2005, Yi Feng wrote:
>
> > The user application can therefore maintain the residence
information of
> > all its pages and cooperate with the kernel under memory pressure.
>
> That seems pretty high overhead. I wonder if it wouldn't work
> similarly well for the kernel to simply notify the registrered
> apps that memory is running low and they should garbage collect
> _something_, without caring which pages.
>
> Then the apps can "shoot holes" in their memory use by calling
> madvise with MADV_DONTNEED on the pages the application judges
> to be the least likely ones to be used again.
>
> OTOH, maybe keeping state for each page is low enough overhead.
> I will have to read your patch to figure out the details ;)
>
> --
> All Rights Reversed
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2005-11-22 21:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 21:53 Emery Berger [this message]
2005-11-23 2:29 ` Rohit Seth
2005-11-23 5:00 ` Yi Feng
2005-11-23 13:11 ` Rik van Riel
2005-11-23 16:30 ` Yi Feng
-- strict thread matches above, loose matches on Subject: below --
2005-11-23 13:33 Emery Berger
2005-11-22 20:54 Yi Feng
2005-11-22 21:45 ` 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=B061F5ED2860D9439AE34EE5C141938C090CDE@zor.ads.cs.umass.edu \
--to=emery@cs.umass.edu \
--cc=akpm@osdl.org \
--cc=hertzm@canisius.edu \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=yifeng@cs.umass.edu \
/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