Re: [RFC][Resend] Make NFS-Client readahead tunable

All of lore.kernel.org
 help / color / mirror / Atom feed

From: Martin Knoblauch <knobi-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
To: Jim Rees <rees@umich.edu>
Cc: linux-nfs list <linux-nfs@vger.kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][Resend] Make NFS-Client readahead tunable
Date: Wed, 17 Sep 2008 09:10:49 -0700 (PDT)	[thread overview]
Message-ID: <766680.7905.qm@web32608.mail.mud.yahoo.com> (raw)

Adding back LKML.


----- Original Message ----
> From: Jim Rees <rees@umich.edu>
> To: Martin Knoblauch <knobi-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> Cc: linux-nfs list <linux-nfs@vger.kernel.org>
> Sent: Wednesday, September 17, 2008 5:31:12 PM
> Subject: Re: [RFC][Resend] Make NFS-Client readahead tunable
> 
> Martin Knoblauch wrote:
> 
>    We never needed that in our case. But yes, would be trivial. The question
>    is, whether there should be a maximum, just as a safeguard.
> 
> Yes.  The default should be (RPC_DEF_SLOT_TABLE - 1), and the maximum should
> be max(xprt_udp_slot_table_entries, xprt_tcp_slot_table_entries) (maybe
> minus one).
> 

The default is NFS_MAX_READAHEAD, which is (RPC_DEF_SLOT_TABLE - 1). Incidentially, your suggested maximum seems to be the same on a default setup (minus one applied).

> I wonder if it would make sense to adjust NFS_MAX_READAHEAD when
> xprt_*_slot_table_entries is changed via sysctl.

I am not sure how useful/practical this is, as currently the ra_factor is applied at mount time.

Cheers
Martin

WARNING: multiple messages have this Message-ID (diff)

From: Martin Knoblauch <knobi@knobisoft.de>
To: Jim Rees <rees@umich.edu>
Cc: linux-nfs list <linux-nfs@vger.kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][Resend] Make NFS-Client readahead tunable
Date: Wed, 17 Sep 2008 09:10:49 -0700 (PDT)	[thread overview]
Message-ID: <766680.7905.qm@web32608.mail.mud.yahoo.com> (raw)

Adding back LKML.


----- Original Message ----
> From: Jim Rees <rees@umich.edu>
> To: Martin Knoblauch <knobi@knobisoft.de>
> Cc: linux-nfs list <linux-nfs@vger.kernel.org>
> Sent: Wednesday, September 17, 2008 5:31:12 PM
> Subject: Re: [RFC][Resend] Make NFS-Client readahead tunable
> 
> Martin Knoblauch wrote:
> 
>    We never needed that in our case. But yes, would be trivial. The question
>    is, whether there should be a maximum, just as a safeguard.
> 
> Yes.  The default should be (RPC_DEF_SLOT_TABLE - 1), and the maximum should
> be max(xprt_udp_slot_table_entries, xprt_tcp_slot_table_entries) (maybe
> minus one).
> 

The default is NFS_MAX_READAHEAD, which is (RPC_DEF_SLOT_TABLE - 1). Incidentially, your suggested maximum seems to be the same on a default setup (minus one applied).

> I wonder if it would make sense to adjust NFS_MAX_READAHEAD when
> xprt_*_slot_table_entries is changed via sysctl.

I am not sure how useful/practical this is, as currently the ra_factor is applied at mount time.

Cheers
Martin

next             reply	other threads:[~2008-09-17 16:10 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17 16:10 Martin Knoblauch [this message]
2008-09-17 16:10 ` [RFC][Resend] Make NFS-Client readahead tunable Martin Knoblauch
  -- strict thread matches above, loose matches on Subject: below --
2008-09-21 12:53 Martin Knoblauch
2008-09-21 12:53 ` Martin Knoblauch
2008-09-21 12:50 Martin Knoblauch
2008-09-21 12:50 ` Martin Knoblauch
     [not found] ` <968192.84087.qm-f6uctMgKLEavuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-21 13:53   ` Chuck Lever
2008-09-21 13:53     ` Chuck Lever
2008-09-18 11:53 Martin Knoblauch
2008-09-18 11:53 ` Martin Knoblauch
     [not found] ` <688309.69831.qm-lSXk2nNw7cevuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-18 18:24   ` Chuck Lever
2008-09-18 18:24     ` Chuck Lever
     [not found]     ` <76bd70e30809181124t78c0d574gaed5702095c02921-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-09-18 19:03       ` Peter Staubach
2008-09-18 19:03         ` Peter Staubach
2008-09-18  9:32 Martin Knoblauch
2008-09-18  9:32 ` Martin Knoblauch
2008-09-18  8:38 Martin Knoblauch
2008-09-18  8:38 ` Martin Knoblauch
     [not found] ` <124712.40022.qm-n7KXdZBPtPqvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-18  8:47   ` Andrew Morton
2008-09-18  8:47     ` Andrew Morton
2008-09-18  8:57     ` Greg Banks
2008-09-18 13:20 ` Peter Zijlstra
2008-09-18  8:19 Martin Knoblauch
2008-09-18  8:19 ` Martin Knoblauch
     [not found] ` <136998.55258.qm-RqHyxEpxwZuvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-18  8:45   ` Greg Banks
2008-09-18  8:45     ` Greg Banks
2008-09-18  7:42 Martin Knoblauch
2008-09-18  7:42 ` Martin Knoblauch
     [not found] ` <418380.19358.qm-1+WuAixcP4WvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-18  8:18   ` Andrew Morton
2008-09-18  8:18     ` Andrew Morton
2008-09-17 17:01 Martin Knoblauch
2008-09-17 17:01 ` Martin Knoblauch
2008-09-17 16:23 Martin Knoblauch
2008-09-17 16:23 ` Martin Knoblauch
     [not found] ` <804604.40886.qm-f6uctMgKLEavuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-17 16:43   ` Chuck Lever
2008-09-17 16:43     ` Chuck Lever
2008-09-17 16:15 Martin Knoblauch
2008-09-17 16:15 ` Martin Knoblauch
2008-09-17 16:03 Martin Knoblauch
2008-09-17 16:03 ` Martin Knoblauch
2008-09-17 13:42 Michael Trimarchi
2008-09-17 13:42 ` Michael Trimarchi
2008-09-17 13:27 Martin Knoblauch
2008-09-17 13:27 ` Martin Knoblauch
2008-09-17 13:25 Martin Knoblauch
     [not found] ` <995475.95604.qm-f6uctMgKLEavuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-17 15:31   ` Jim Rees
2008-09-17 13:19 Michael Trimarchi
2008-09-17 13:19 ` Michael Trimarchi
2008-09-17 13:06 Martin Knoblauch
2008-09-17 13:06 ` Martin Knoblauch
     [not found] ` <997439.5560.qm-VAEUvbQToQWvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-09-17 13:21   ` Jim Rees
2008-09-17 14:06   ` Peter Staubach
2008-09-17 14:06     ` Peter Staubach
2008-09-17 15:41     ` Chuck Lever
2008-09-17 15:41       ` Chuck Lever
2008-09-18  1:42   ` Greg Banks
2008-09-18  1:42     ` Greg Banks
     [not found]     ` <48D1B21E.3060509-cP1dWloDopni96+mSzHFpQC/G2K4zDHf@public.gmane.org>
2008-09-18  3:13       ` Andrew Morton
2008-09-18  3:13         ` Andrew Morton

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=766680.7905.qm@web32608.mail.mud.yahoo.com \
    --to=knobi-ys4e+72pfw0hfhg+jk9f0w@public.gmane.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    /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.