lkml.org 
[lkml]   [2004]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat
Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>

>>Apparently these (higher-order && !wait) come up mainly in networking
>>which is the thing I had in mind. *However* as I only have half of a
>>gigabit network (ie. 1 card), I haven't done any testing where it
>>really counts. I'm also seeing surprisingly few reports on lkml, so
>>perhaps it is me that needs the beating?
>
>
> There have been few reports, and I believe that networking is getting
> changed to reduce the amount of GFP_ATOMIC higher-order allocation
> attempts.
>

That is the ideal goal, I think. But while our allocator offers higher
order allocations, we *should* be a bit smarter about them.

> There have been multiple instances in the past year or so where we've made
> changes in there, the changes were not adequately tested and stuff broke in
> subtle ways. We need to raise the bar a bit - clearly demonstrate that we
> have a problem, and then demonstrate that the fix fixes it, then worry
> about side-effects.
>

Yep. As you see I've already corrected myself a couple of times :\
RFC only at this stage.

>
> I don't see anything in your code which directly prevents the following
> serious scenario:
>
> a) Some random 0-order allocation causes a 4-order page to be split up,
> taking the 4-order pool below threshold.
>
> b) kswapd goes berzerk reclaiming 9000 pages to replenish the 4-order
> pool even though we don't need it.
>
> You have arith in there which kinda-sorta prevents it, but I don't see any
> hard-and-fast protection. Or did I miss it?
>

Yep. Kswapd will not care about 4-order allocations unless someone does
a wake_kswapd(order 4);

We could get into a situation where kswapd free smore than required, but
if you've got someone regularly allocating 4-order pages, it probably
isn't *that* dumb to free one or two more.

If we complete an entire balance_pgdat round without freeing the required
pages, that kswapd_max_order gets reset to zero anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:5.703 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site