Re: [patch 4/5] mm: writeback: throttle __GFP_WRITE on per-zonedirty limits

[Andi Kleen]

> The global dirty limits are put in proportion to the respective zone's
> amount of dirtyable memory and the allocation denied when the limit of
> that zone is reached.
> 
> Before the allocation fails, the allocator slowpath has a stage before
> compaction and reclaim, where the flusher threads are kicked and the
> allocator ultimately has to wait for writeback if still none of the
> zones has become eligible for allocation again in the meantime.
> 

I don't really like this. It seems wrong to make memory
placement depend on dirtyness.

Just try to explain it to some system administrator or tuner: her 
head will explode and for good reasons.

On the other hand I like doing round-robin in filemap by default
(I think that is what your patch essentially does)
We should have made  this default long ago. It avoids most of the
"IO fills up local node" problems people run into all the time.

So I would rather just change the default in filemap allocation.

That's also easy to explain.

BTW the original argument why this wasn't done was that it may
be a problem on extremly large systems, but I think it's reasonable
to let these oddballs change their defaults instead of letting
everyone else handle them.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/