On Oct 5, 2009, at 3:11, "Wu Fengguang" <fengguang.wu@xxxxxxxxx> wrote:
Hi all,
This version makes two standalone functions for easier reuse.
Before patch, nr_writeback is near 1G on my 2GB laptop:
nr_writeback nr_dirty nr_unstable
203994 2 154469
203994 2 154469
After patch, nr_writeback is limited to nfs_congestion_kb=42MB.
nr_writeback nr_dirty nr_unstable
11180 34195 11754
9865 36821 8234
10137 36695 9338
One minor problem I noticed is, NFS writeback is not very smooth.
This per 0.1s sampled trace shows that it can sometimes stuck for
up to 0.5s:
nr_writeback nr_dirty nr_unstable
11055 37408 9599
10311 37315 10529
10869 35920 11459
10869 35920 11459
10869 35920 11459
10869 35920 11459
10869 35920 11459
10838 35891 10042
10466 35891 10414
10900 34744 11437
10249 34744 12088
10249 34744 12088
10249 34744 12088
10249 34744 12088
10249 34744 12088
10249 34744 12088
10133 34743 10663
10505 34743 11035
10970 34991 11345
10691 34991 11593
10691 34991 11593
10691 34991 11593
10691 34991 11593
10691 34991 11593
Trond, I guess nr_writeback/nr_unstable are decreased in async RPC
"complete" events. It is understandable that nr_dirty can sometimes
stuck on local waits, but the "local determined" nr_dirty and "remote
determined" nr_writeback/nr_unstable tend to stuck at the same time?
Did I miss something (that could be obvious to you)?
It looks (at 7am in the morning after getting up at 4:30am) as though
the number of unstable pages is remaining constant, which would mean
that we're sending a lot of COMMIT requests (see nfsstat). Since
COMMIT is essentially an fsync call, it means that the server is going
to be slower.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
