lkml.org 
[lkml]   [2007]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/5] make slab gfp fair
On Wed, 16 May 2007, Peter Zijlstra wrote:

> > Hmmm.. so we could simplify the scheme by storing the last rank
> > somewheres.
>
> Not sure how that would help..

One does not have a way of determining the current processes
priority? Just need to do an alloc?

If we had the current processes "rank" then we could simply compare.
If rank is okay give them the object. If not try to extend slab. If that
succeeds clear the rank. If extending fails fail the alloc. There would be
no need for a reserve slab.

What worries me about this whole thing is


1. It is designed to fail an allocation rather than guarantee that all
succeed. Is it not possible to figure out which processes are not
essential and simply put them to sleep until the situation clear up?

2. It seems to be based on global ordering of allocations which is
not possible given large systems and the relativistic constraints
of physics. Ordering of events get more expensive the bigger the
system is.

How does this system work if you can just order events within
a processor? Or within a node? Within a zone?

3. I do not see how this integrates with other allocation constraints:
DMA constraints, cpuset constraints, memory node constraints,
GFP_THISNODE, MEMALLOC, GFP_HIGH.

-
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: 2007-05-16 23:47    [W:0.114 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site