On Sat, 25 Aug 2001, Roger Larsson wrote:
> Hi again,
Howdy,
> [two typos corrected from the version at linux-mm]
>
> I read through __alloc_pages again and found out that allocs with order > 0
> are not treated nicely.
But they shouldn't be treated _too_ nicely ;-) IMHO, you should never
exaust the entire clean list trying to service a high order allocation.
These allocations can wait.
> To begin with if order > 0 then direct_reclaim will be false even if it is
> allowed to wait...
>
> This version allows "direct_reclaim" with order > 0 !
>
> How?
>
> Like we finally end up doing anyway...
> reclaiming pages and freeing.
Yes, and the way we currently do it endangers other allocations in
that the effect the high order allocation will have upon the zone is
not accounted for. If we're at that point, servicing a high order
allocation, and you actually succeed in assembling that possibly BIG
chunk, you may deplete the zone and leave yourself in a situation where
you can't service an incoming burst of atomic allocations. That makes
drivers that try fallback allocations happy, but can hurt like heck.
If the thing continues to fail, you're also in pain, because the entire
time you're reclaiming, you're eating cached data for possibly no gain.
> While adding this I thought why not always do it like this,
> even with order == 0?
> since it will allow for merging of pages to higher orders.
> Before returning a page that was not mergeable...
>
> Doing this - the code started to collaps...
> __alloc_pages_limit could suddenly handle all special cases!
> (with small functional differences)
>
> Comments?
+ /* Always alloc via rmqueue */
That adds overhead to order 0 allocations.
MHO:
I think the easiest way to handle high order allocations is to do _low_
volume background reclamation if high order allocations might fail. ie
put a little effort into keeping such allocations available, but don't
do massive effort. Cache tends to lose it's value over time, so dumping
small quantities over time shouldn't hurt. This would also have the
benefit of scanning the inactive lists even when there's little activity
so that list information (page accessed _yesterday_?) won't get stale.
I think it's ~fine to reclaim for up to say order 2, but beyond that, it
doesn't have any up side that I can see.. only down.
btw, I wonder why we don't do memory_pressure [+-]= 1 << order.
-Mike
-
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 Aug 31 2001 - 21:00:17 EST