On Mon, Sep 25, 2000 at 06:18:17PM +0200, Andi Kleen wrote:
> On Mon, Sep 25, 2000 at 06:19:07PM +0200, Ingo Molnar wrote:
> > > Another thing I would worry about are ports with multiple user page
> > > sizes in 2.5. Another ugly case is the x86-64 port which has 4K pages
> > > but may likely need a 16K kernel stack due to the 64bit stack bloat.
> >
> > yep, but these cases are not affected, i think in the order != 0 case we
> > should return NULL if a certain number of iterations did not yield any
> > free page.
>
> Ok, that would just break fork()
Not sure if I have the whole context (I've not yet received Ingo's email
that you're replying to).
Currently we do a memory balancing pass indipendently by the order of the
allocation. Thus we don't do any iteraction and the memory balancing
is completly order blind (unfortunately it's also zone blind, while
at least in 2.2.x the memory balancing known which zone it had
to allocate memory from).
If Ingo suggested more iteractions of memory balancing for those cases
that should only make things better with respect to fragmentation.
But I'd much prefer to pass not only the classzone from allocator
to memory balancing, but _also_ the order of the allocation,
and then shrink_mmap will know it doesn't worth to free anything
that isn't contigous on the order of the allocation that we need.
classzone haven't reached this point yet.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:15 EST