Re: [PATCH 3/6] cpuset write throttle

[Christoph Lameter <clameter@sgi.com>]

On Wed, 3 Oct 2007, Ethan Solomita wrote:

> >> 	Unfortunately this eliminates one of the main reasons for the
> >> per-cpuset throttling. If one cpuset is responsible for pushing one
> >> disk/BDI to its dirty limit, someone in another cpuset can get throttled.
> > 
> > I think that is acceptable. All processes that write to one disk/BDI must 
> > be affected by congestion on that device. We may have to deal with 
> > fairness issues later if it indeed becomes a problem.
> 
> 	We do see a fairness issue. We've seen delays on the order of 100
> seconds for just a few writes to disk, and latency is important to us.
> Perhaps we can detect that the bdi already has a long queue of pending
> writes and not force more writes at this time so long as the per-cpuset
> dirty threshold is not too high.

Arghy.

> 	On a side note, get_dirty_limits() now returns two dirty counts, both
> the dirty and bdi_dirty, yet its callers only ever want one of those
> results. Could we change get_dirty_limits to only calculate one dirty
> value based upon whether bdi is non-NULL? This would save calculation of
> regular dirty when a bdi is passed.

Hmmmm.... I think Peter needs to consider this.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>