Nick Piggin wrote:
>
> [email protected] wrote:
> > [email protected]
> > Sent: Friday, August 24, 2007 3:11 PM
> > Subject: Re: [RFC] : mm : / Patch / code : Suggestion :snip kswapd &
> > get_page_from_freelist() : No more no page failures.
> >
> > Mailer added a HTML subpart and chopped the earlier email.... :^(
>
> Hi Mitchell,
>
> Is it possible to send suggestions in the form of a unified diff, even
> if you haven't even compiled it (just add a note to let people know).
>
> Secondly, we already have a (supposedly working) system of asynch
> reclaim, with buffering and hysteresis. I don't exactly understand
> what problem you think it has that would be solved by rechecking
> watermarks after allocating a page.
>
> When we're in the (min,low) watermark range, we'll wake up kswapd
> _before_ allocating anything, so what is better about the change to
> wake up kswapd after allocating? Can you perhaps come up with an
> example situation also to make this more clear?
>
> Overhead of wakeup_kswapd isn't too much of a problem: if we _should_
> be waking it up when we currently aren't, then we should be calling
> it. However the extra checking in the allocator fastpath is something
> we want to avoid if possible, because this can be a really hot path.
>
> Thanks,
> Nick
>
> --
> SUSE Labs, Novell Inc.
> -
--------
Nick Piggin, et al,
First diffs would generate alot of noise, since I rip and insert
alot of code based on whether I think the code is REALLY
needed for MY TEST environment. These suggestions are
basicly minimal merge suggestions between my
development envir and the public Linux tree.
Now the why for this SUGGESTION/PATCH...
> When we're in the (min,low) watermark range, we'll wake up kswapd
> _before_ allocating anything, so what is better about the change to
> wake up kswapd after allocating? Can you perhaps come up with an
> example situation also to make this more clear?
Answer
Will GFP_ATOMIC alloc be failing at that point? If yes, then why
not allow kswapd attempt to prevent this condition from occuring?
The existing code reads that the first call to get_page_from_freelist()
has returned no page. Now you are going to start up something that
is at best going to take millisecs to start helping out. Won't it first
grab some pages to do its work? So we are going to be lower
in free memory right when it starts up. Right?
So, before the change, with high memory consumption/pressure,
various GFP_xxx allocations would fail or take an excessive
amount of time due to the simple fact of low memory and/or
Slub/slab consumption and/or first failure of
get_page_from_freelist() when in a low free memory condition.
Once the above condition occurs the perception is that the
current mainline Linux code then on demand increases its
effort to find some memory. However, while this is happening
the system is in a low memory bind and various performance
parameters are being effected and some allocations are
sleeping or being delayed or outright failing.
What I could see is that CURR suggestions allow a new class
of GFP_xxx allocations to succeed while in low memory,
try again philosophy, wake-up kswapd , etc, are all AFTER the
fact while something is WAITING for the memory. This
wait is in effect a SYNCHRONOUS wait for memory.
Assuming that kswapd is really what is mostly needed.
Execute it BEFORE (JUST IN TIME) to PREVENT low
memory since I/O needs pages and GFP_ATOMIC
allocs fails and other GFP allocs sleeeeeping and....
The SUGGESTION is to
take the fraction of microsec longer in the fast path to see if
it is needed to be started up and to ATTEMPT to prevent
the SLOW-PATH and low/min memory from occuring.
The 2x low memory is
to allow some scalability and to allow it ENOUGH time to do what
it needs to do, since I expect a minimum number of millisecs
before it can move us away from low free memory. As the
amount of memory increases in a system this probably could
be decreased somewhat to maybe 1.25x.
IF the above is good then the issue is how to optimize the heck
out of the check.
Mitchell Erblich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
