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