Re: [PATCH] mem notifications v2

["Daniel Spång" <daniel.spang@gmail.com>]

On 11/23/07, Rik van Riel <riel@redhat.com> wrote:
> On Fri, 23 Nov 2007 01:27:38 +0100
> "Daniel Spang" <daniel.spang@gmail.com> wrote:
>
> > On 11/22/07, Rik van Riel <riel@redhat.com> wrote:
> > > On Thu, 22 Nov 2007 12:23:55 +0100
> > > "Daniel Spang" <daniel.spang@gmail.com> wrote:
> > >
> > > > When the page cache is filled, the notification is a bit early as the
> > > > following example shows on a small system with 64 MB ram and no swap.
> > > > On the first run the application can use 58 MB of anonymous pages
> > > > before notification is sent. Then after the page cache is filled the
> > > > test application is runned again and is only able to use 49 MB before
> > > > being notified.
> > >
> > > Excellent.  Throwing away useless memory when three is still
> > > useful memory available sounds like a good idea.
> > >
> > > > I see it as a feature to be able to throw out inactive binaries and
> > > > mmaped files before getting notified about low memory.
> > >
> > > I think that once you get low on memory, you want a bit of
> > > both.  Inactive binaries and mmaped files are potentially
> > > useful; in-process free()d memory and caches are just as
> > > potentially (dubiously) useful.
> > >
> > > Freeing a bit of both will probably provide a good compromise
> > > between CPU and memory efficiency.
> >
> > I get your point, but strictly speaking, it is never freeing inactive
> > binaries nor mapped files until all in-process cache are freed. But
> > your argument is still valid, although a tad weaker, if you replace
> > ``inactive binaries and mmaped files'' with ``page cache''.
>
> How can you say that when you do not know how many userland
> processes will get woken up, or how much memory they will
> free?
>
> The kernel sends the notification in *addition* to freeing
> page cache, not instead of freeing page cache.

Ok, ``never freeing'' and ``all in-process cache'' was a slight
exaggeration. However, I did some tests that show that if a process,
polling on the device and able to free some memory rather quickly, not
much mmaped file backed memory will be thrown out after each
notification.

Note that I'm not against this early notification per se, just that I
think there is a need for a later notification too.

--
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>