All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] cifs: don't cap ra_pages at the same level as default_backing_dev_info
Date: Wed, 02 May 2012 18:12:26 +0530	[thread overview]
Message-ID: <4FA12BB2.2040708@suse.com> (raw)
In-Reply-To: <1335909117-17314-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On 05/02/2012 03:21 AM, Jeff Layton wrote:
> While testing, I've found that even when we are able to negotiate a
> much larger rsize with the server, on-the-wire reads often end up being
> capped at 128k because of ra_pages being capped at that level.
> 
> Lifting this restriction gave almost a twofold increase in sequential
> read performance on my craptactular KVM test rig with a 1M rsize:
> 
> $ dd if=./ddtest.out of=/dev/null bs=1M count=1024
> 
> Prepatch:
> 1048576000 bytes (1.0 GB) copied, 28.1979 s, 37.2 MB/s
> 
> Postpatch:
> 1048576000 bytes (1.0 GB) copied, 11.92 s, 88.0 MB/s
> 
> I think this is safe since the actual ra_pages that the VM requests
> is run through max_sane_readahead() prior to submitting the I/O. Under
> memory pressure we should end up with large readahead requests being
> suppressed anyway.

Yeah, it seems safer to me as well.

Wondering whether we need to just verify with small memory systems (or
restricting physical memory with "mem=" ) to ensure that the latency is
OK... but then if that is the case the user consciously asked for it
with explicit larger rsize so even if the latency is high it shouldn't
be a problem I think.


> Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  fs/cifs/connect.c |   18 +-----------------
>  1 files changed, 1 insertions(+), 17 deletions(-)
> 
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 0d783e2..d41a4a8 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -3705,22 +3705,6 @@ cifs_get_volume_info(char *mount_data, const char *devname)
>  	return volume_info;
>  }
>  
> -/* make sure ra_pages is a multiple of rsize */
> -static inline unsigned int
> -cifs_ra_pages(struct cifs_sb_info *cifs_sb)
> -{
> -	unsigned int reads;
> -	unsigned int rsize_pages = cifs_sb->rsize / PAGE_CACHE_SIZE;
> -
> -	if (rsize_pages >= default_backing_dev_info.ra_pages)
> -		return default_backing_dev_info.ra_pages;
> -	else if (rsize_pages == 0)
> -		return rsize_pages;
> -
> -	reads = default_backing_dev_info.ra_pages / rsize_pages;
> -	return reads * rsize_pages;
> -}
> -
>  int
>  cifs_mount(struct cifs_sb_info *cifs_sb, struct smb_vol *volume_info)
>  {
> @@ -3808,7 +3792,7 @@ try_mount_again:
>  	cifs_sb->rsize = cifs_negotiate_rsize(tcon, volume_info);
>  
>  	/* tune readahead according to rsize */
> -	cifs_sb->bdi.ra_pages = cifs_ra_pages(cifs_sb);
> +	cifs_sb->bdi.ra_pages = cifs_sb->rsize / PAGE_CACHE_SIZE;
>  
>  remote_path_check:
>  #ifdef CONFIG_CIFS_DFS_UPCALL

      parent reply	other threads:[~2012-05-02 12:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-01 21:51 [PATCH] cifs: don't cap ra_pages at the same level as default_backing_dev_info Jeff Layton
     [not found] ` <1335909117-17314-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-05-02 12:42   ` Suresh Jayaraman [this message]

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=4FA12BB2.2040708@suse.com \
    --to=sjayaraman-ibi9rg/b67k@public.gmane.org \
    --cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.