On September 2, 2001 04:21 am, Roger Larsson wrote:
> On Sunday den 2 September 2001 03:57, Daniel Phillips wrote:
> > In some sense, it's been good to have the issue
> > forced so that we must come up with ways to make atomic and higher order
> > allocations less fragile.
>
> It might be that the elevator works now... :-)
You think it's the elevator? It could be, but scanning policy seems much
more likely.
> You will only see it once there are no remaining free pages of an even
> higher order left - then you will start to fail...
>
> Two things are required:
> 1) You have lots of memory.
Actually, the situation improves a little as you add memory. I'll show that
mathematically tomorrow.
> 2) You have used it all at some point.
This is the normal case, except for startup and a few special situations such
as after heavy file deletion or unmounting a volume.
> Another thing to do could be to add a order parameter to free.
> The pages allocated has to be freed sometime... if we make sure that
> they are freed together it could simplify things - no chance that the
> first part gets allocated directly...
We must be getting a little bit of avoidable fragmentation on freeing, but
the real culprit is allocation, which tends to split up higher order
allocations rapidly.
> Or/and we could remove the sources of higher order allocs, as an example:
> why is the SCSI layer allowed to allocate order 3 allocs (32 kB) several
> times per second? Will we really get a performance hit by not allowing
> higher order allocs in active driver code?
Yes, well, if we make it work properly that might not be necessary ;-)
I imagine a lot of higher order allocations could be removed without hurting
performance, for example, where dma can handle non-physically-contiguous
regions (i.e., scatter/gather). On the other hand, leaving them just the way
they are creates more incentive to fix the damn thing, not to mention
providing the needed test cases.
-- Daniel - 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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:13 EST