[lkml]   [2007]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 0/8] Cpuset aware writeback
On Thu, 1 Feb 2007, Andrew Morton wrote:

> > Peter Zilkstra addressed the NFS issue.
> Did he? Are you yet in a position to confirm that?

He provided a solution to fix the congestion issue in NFS. I thought
that is what you were looking for? That should make NFS behave more
like a block device right?

As I said before I think NFS is inherently unfixable given the layering of
a block device on top of the network stack (which consists of an unknown
number of additional intermediate layers). Cpuset writeback needs to work
in the same way as in a machine without cpusets. If fails then at least
let the cpuset behave as if we had a machine all on our own and fail in
both cases in the same way. Right now we create dangerous low memory
conditions due to high dirty ratios in a cpuset created by not having a
throttling method. The NFS problems also exist for non cpuset scenarios
and we have by and large been able to live with it so I think they are
lower priority. It seems that the basic problem is created by the dirty
ratios in a cpuset.

BTW the block layer also may be layered with raid and stuff and then we
have similar issues. There is no general way so far of handling these
situations except by twiddling around with min_free_kbytes praying 5 Hail
Mary's and trying again. Maybe we are able allocate all needed memory from
PF_MEMALLOC processes during reclaim and hopefully there is now enough
memory for these allocations and those that happen to occur during an
interrupt while we reclaim.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-02 06:31    [W:0.158 / U:11.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site