On Friday 14 December 2007 07:39, Peter Zijlstra wrote:
> Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to
> allocation contexts that are entitled to it. This is done to ensure
> reserve pages don't leak out and get consumed.
Tighter definitions of "leak out" and "get consumed" would be helpful
here. As I see it, the chain of reasoning is:
* Any MEMALLOC mode allocation must have come from a properly
throttled path and has a finite lifetime that must eventually
produce writeout progress.
* Since the transaction that made the allocation was throttled and
must have a finite lifetime, we know that it must eventually return
the resources it consumed to the appropriate resource pool.
Now, I think what you mean by "get consumed" and "leak out" is: "become
pinned by false sharing with other allocations that do not guarantee
that they will be returned to the resource pool". We can say "pinned"
for short.
So you are attempting to prevent slab pages from becoming pinned by
users that do not obey the reserve management rules, which I think your
approach achieves. However...
Note that false sharing of slab pages is still possible between two
unrelated writeout processes, both of which obey rules for their own
writeout path, but the pinned combination does not. This still leaves
a hole through which a deadlock may slip.
My original solution was simply to allocate a full page when drawing
from the memaloc reserve, which may use a tad more reserve, but makes
it possible to prove the algorithm correct.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
