public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <wfg@mail.ustc.edu.cn>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Wu Fengguang <wfg@mail.ustc.edu.cn>,
	Neil Brown <neilb@cse.unsw.edu.au>
Subject: [PATCH 29/33] readahead: nfsd case
Date: Fri, 26 May 2006 19:39:35 +0800	[thread overview]
Message-ID: <348644391.06434@ustc.edu.cn> (raw)
Message-ID: <20060526115316.335626686@localhost.localdomain> (raw)
In-Reply-To: 20060526113906.084341801@localhost.localdomain

[-- Attachment #1: readahead-nfsd-case.patch --]
[-- Type: text/plain, Size: 4646 bytes --]

Bypass nfsd raparms cache -- the new logic do not rely on it.

--------------------------------
For the case of NFS service, the new read-ahead logic
+ can handle disordered nfsd requests
+ can handle concurrent sequential requests on large files
  with the help of look-ahead
- will have much ado about the concurrent ones on small files

--------------------------------
Notes about the concurrent nfsd requests issue:

nfsd read requests can be out of order, concurrent and with no ra-state info.
They are handled by the context based read-ahead method, which does the job
in the following steps:

1. scan in page cache
2. make read-ahead decisions
3. alloc new pages
4. insert new pages to page cache

A single read-ahead chunk in the client side will be dissembled and serviced
by many concurrent nfsd in the server side. It is highly possible for two or
more of these parallel nfsd instances to be in step 1/2/3 at the same time.
Without knowing others working on the same file region, they will issue
overlapped read-ahead requests, which lead to many conflicts at step 4.

There's no much luck to eliminate the concurrent problem in general and
efficient ways. But experiments show that mount with tcp,rsize=32768 can
cut down the overhead a lot.

--------------------------------
Here are the benchmark outputs. The test cases cover
- small/big files
- small/big rsize mount option
- serialized/parallel nfsd processing

`serialized' means running the following command to enforce serialized
nfsd requests processing:

# for pid in `pidof nfsd`; do taskset -p 1 $pid; done

8 nfsd; local mount with tcp,rsize=8192
=======================================

SERIALIZED, SMALL FILES
readahead_ratio = 0, ra_max = 128kb (old logic, the ra_max is not quite relevant)
96.51s real  11.32s system  3.27s user  160334+2829 cs  diff -r $NFSDIR $NFSDIR2
readahead_ratio = 70, ra_max = 1024kb (new read-ahead logic)
94.88s real  11.53s system  3.20s user  152415+3777 cs  diff -r $NFSDIR $NFSDIR2

SERIALIZED, BIG FILES
readahead_ratio = 0, ra_max = 128kb
56.52s real  3.38s system  1.23s user  47930+5256 cs  diff $NFSFILE $NFSFILE2
readahead_ratio = 70, ra_max = 1024kb
32.54s real  5.71s system  1.38s user  23851+17007 cs  diff $NFSFILE $NFSFILE2

PARALLEL, SMALL FILES
readahead_ratio = 0, ra_max = 128kb
99.87s real  11.41s system  3.15s user  173945+9163 cs  diff -r $NFSDIR $NFSDIR2
readahead_ratio = 70, ra_max = 1024kb
100.14s real  12.06s system  3.16s user  170865+13406 cs  diff -r $NFSDIR $NFSDIR2

PARALLEL, BIG FILES
readahead_ratio = 0, ra_max = 128kb
63.35s real  5.68s system  1.57s user  82594+48747 cs  diff $NFSFILE $NFSFILE2
readahead_ratio = 70, ra_max = 1024kb
33.87s real  10.17s system  1.55s user  72291+100079 cs  diff $NFSFILE $NFSFILE2

8 nfsd; local mount with tcp,rsize=32768
========================================
Note that the normal data are now much better, and come close to that of the
serialized ones.

PARALLEL/NORMAL

readahead_ratio = 8, ra_max = 1024kb (old logic)
48.36s real  2.22s system  1.51s user  7209+4110 cs  diff $NFSFILE $NFSFILE2
readahead_ratio = 70, ra_max = 1024kb (new logic)
30.04s real  2.46s system  1.33s user  5420+2492 cs  diff $NFSFILE $NFSFILE2

readahead_ratio = 8, ra_max = 1024kb
92.99s real  10.32s system  3.23s user  145004+1826 cs  diff -r $NFSDIR $NFSDIR2 > /dev/null
readahead_ratio = 70, ra_max = 1024kb
90.96s real  10.68s system  3.22s user  144414+2520 cs  diff -r $NFSDIR $NFSDIR2 > /dev/null

SERIALIZED

readahead_ratio = 8, ra_max = 1024kb
47.58s real  2.10s system  1.27s user  7933+1357 cs  diff $NFSFILE $NFSFILE2
readahead_ratio = 70, ra_max = 1024kb
29.46s real  2.41s system  1.38s user  5590+2613 cs  diff $NFSFILE $NFSFILE2

readahead_ratio = 8, ra_max = 1024kb
93.02s real  10.67s system  3.25s user  144850+2286 cs  diff -r $NFSDIR $NFSDIR2 > /dev/null
readahead_ratio = 70, ra_max = 1024kb
91.15s real  11.04s system  3.31s user  144432+2814 cs  diff -r $NFSDIR $NFSDIR2 > /dev/null

Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn>
---


Greg Banks gives a valuable recommend on the test cases, which helps me to
get the more complete picture. Thanks!

 fs/nfsd/vfs.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletion(-)

--- linux-2.6.17-rc4-mm3.orig/fs/nfsd/vfs.c
+++ linux-2.6.17-rc4-mm3/fs/nfsd/vfs.c
@@ -829,7 +829,10 @@ nfsd_vfs_read(struct svc_rqst *rqstp, st
 #endif
 
 	/* Get readahead parameters */
-	ra = nfsd_get_raparms(inode->i_sb->s_dev, inode->i_ino);
+	if (prefer_adaptive_readahead())
+		ra = NULL;
+	else
+		ra = nfsd_get_raparms(inode->i_sb->s_dev, inode->i_ino);
 
 	if (ra && ra->p_set)
 		file->f_ra = ra->p_ra;

--

  parent reply	other threads:[~2006-05-26 11:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060526113906.084341801@localhost.localdomain>
     [not found] ` <20060526115259.223408850@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 02/33] radixtree: introduce __radix_tree_lookup_parent() Wu Fengguang
2006-05-26 13:56     ` Christoph Lameter
     [not found]       ` <20060526140951.GA13954@mail.ustc.edu.cn>
2006-05-26 14:09         ` Wu Fengguang
     [not found] ` <20060526115259.809011306@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 03/33] radixtree: introduce radix_tree_scan_hole[_backward]() Wu Fengguang
     [not found] ` <20060526115300.609227164@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 04/33] mm: introduce probe_pages() Wu Fengguang
     [not found] ` <20060526115301.640751284@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 06/33] readahead: add look-ahead support to __do_page_cache_readahead() Wu Fengguang
     [not found] ` <20060526115302.278500703@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 07/33] readahead: delay page release in do_generic_mapping_read() Wu Fengguang
     [not found] ` <20060526115303.499451943@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 09/33] readahead: {MIN,MAX}_RA_PAGES Wu Fengguang
     [not found] ` <20060526115304.094503892@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 10/33] readahead: events accounting Wu Fengguang
     [not found] ` <20060526115304.821789643@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 11/33] readahead: rescue_pages() Wu Fengguang
     [not found] ` <20060526115305.437903777@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 12/33] readahead: sysctl parameters Wu Fengguang
     [not found] ` <20060526115306.535453644@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 14/33] readahead: state based method - aging accounting Wu Fengguang
     [not found] ` <20060526115307.794859372@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 16/33] readahead: state based method Wu Fengguang
     [not found] ` <20060526115308.522890112@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 17/33] readahead: context " Wu Fengguang
     [not found] ` <20060526115309.581525784@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 19/33] readahead: initial method - thrashing guard size Wu Fengguang
     [not found] ` <20060526115310.948231030@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 21/33] readahead: initial method - user recommended size Wu Fengguang
     [not found] ` <20060526115311.541535720@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 22/33] readahead: initial method Wu Fengguang
     [not found] ` <20060526115312.145248016@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 23/33] readahead: backward prefetching method Wu Fengguang
     [not found] ` <20060526115313.491576583@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 25/33] readahead: thrashing recovery method Wu Fengguang
     [not found] ` <20060526115314.929319286@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 26/33] readahead: call scheme Wu Fengguang
     [not found] ` <20060526115315.823465555@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 28/33] readahead: loop case Wu Fengguang
     [not found] ` <20060526115316.335626686@localhost.localdomain>
2006-05-26 11:39   ` Wu Fengguang [this message]
     [not found] ` <20060526115316.925345724@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 30/33] readahead: turn on by default Wu Fengguang
     [not found] ` <20060526115317.663871267@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 31/33] readahead: debug radix tree new functions Wu Fengguang
     [not found] ` <20060526115318.181350700@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 32/33] readahead: debug traces showing accessed file names Wu Fengguang
     [not found] ` <20060526115318.520512078@localhost.localdomain>
2006-05-26 11:39   ` [PATCH 33/33] readahead: debug traces showing read patterns Wu Fengguang
     [not found] <20060524111246.420010595@localhost.localdomain>
     [not found] ` <20060524111911.607080495@localhost.localdomain>
2006-05-24 11:13   ` [PATCH 29/33] readahead: nfsd case Wu Fengguang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=348644391.06434@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox