All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: andros@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/3] SUNRPC add deferral processing callbacks
Date: Mon, 20 Oct 2008 14:42:19 -0400	[thread overview]
Message-ID: <20081020184219.GA25796@fieldses.org> (raw)
In-Reply-To: <RTPCLUEXC1-PRDf3sll000001cb-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>

On Fri, Oct 17, 2008 at 04:35:28PM -0400, Talpey, Thomas wrote:
> >diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> >index dc69068..46a4097 100644
> >--- a/include/linux/sunrpc/svc.h
> >+++ b/include/linux/sunrpc/svc.h
> >@@ -215,6 +215,9 @@ struct svc_rqst {
> > 	struct svc_cred		rq_cred;	/* auth info */
> > 	void *			rq_xprt_ctxt;	/* transport specific context ptr */
> > 	struct svc_deferred_req*rq_deferred;	/* deferred request we are replaying */
> >+	/* callback to save deferred request state */
> >+	void (*rq_save_state)(struct svc_rqst *, struct svc_deferred_req *);
> >+	void			*rq_defer_data; /* defer state data to save */
> > 
> > 	size_t			rq_xprt_hlen;	/* xprt header len */
> > 	struct xdr_buf		rq_arg;
> >@@ -323,6 +326,13 @@ struct svc_deferred_req {
> > 	union svc_addr_u	daddr;	/* where reply must come from */
> > 	struct cache_deferred_req handle;
> > 	size_t			xprt_hlen;
> >+	/* callbacks to restore and release deferred request state
> >+	* set in rq_save_state */
> >+	void (*restore_state)(struct svc_rqst *, struct svc_deferred_req *);
> >+	void (*release_state)(struct svc_deferred_req *);
> >+	void			*defer_data; /* defer state data */
> >+	struct page		*respages[RPCSVC_MAXPAGES];
> 
> Is it worthwhile to make this a dynamically allocated pointer? If the max
> pages size is large (1MB means 256),

So that's a 1k array with 32 bit pointers, a 2k array with 64.  We
currently allow a  maximum of 300 deferred requests (DFR_MAX in
net/sunrpc/cache.c).

It'd be nice to not turn that into two allocations if the typical case
only requires one page, so we'd probably want to allow either a single
page pointer or a dynamically-allocated array.

I don't know how much to care.

--b.

> it's quite a large array for something
> that may rarely be so full.

  parent reply	other threads:[~2008-10-20 18:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 21:00 [PATCH 0/3] NFSD EOS deferral andros
2008-10-15 21:00 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros
2008-10-15 21:00   ` [PATCH 2/3] NFSD save, restore, and release deferred result pages andros
2008-10-15 21:00     ` [PATCH 3/3] NFSD deferral processing andros
2008-10-17 20:46       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDNY30k000001cc-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 17:58           ` J. Bruce Fields
2008-10-17 17:48   ` [PATCH 1/3] SUNRPC add deferral processing callbacks J. Bruce Fields
2008-10-17 18:42     ` Andy Adamson
2008-10-17 20:35   ` Talpey, Thomas
     [not found]     ` <RTPCLUEXC1-PRDf3sll000001cb-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:42       ` J. Bruce Fields [this message]
2008-10-17 17:44 ` [PATCH 0/3] NFSD EOS deferral J. Bruce Fields
2008-10-17 18:44   ` Andy Adamson
2008-10-17 18:59   ` Marc Eshel
     [not found]     ` <OF9E4C4BA6.37418EC7-ON882574E5.0067FB2B-882574E5.0068487F@ us.ibm.com>
2008-10-17 20:26       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDidcDj000001ca-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-17 20:36           ` J. Bruce Fields
2008-10-17 20:51             ` Talpey, Thomas
     [not found]               ` <RTPCLUEXC1-PRDarcR4000001cd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:06                 ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2008-10-22 18:12 andros
2008-10-22 18:12 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros

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=20081020184219.GA25796@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Thomas.Talpey@netapp.com \
    --cc=andros@netapp.com \
    --cc=linux-nfs@vger.kernel.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.