All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Boaz Harrosh <openosd@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/4] pnfs: factor GETDEVICEINFO implementations
Date: Tue, 12 Aug 2014 14:21:56 +0200	[thread overview]
Message-ID: <20140812122156.GA16362@lst.de> (raw)
In-Reply-To: <53E9FC57.9010806@gmail.com>

[Can you please trim your quotes?  Quoting 700+ lines of a patch for
 a 30 line reply is completely unreasonable, and placing the reply in
 the middle of it is even worse.  I will ignore mails ignoring the
 netiquette this blatantly in the future]

On Tue, Aug 12, 2014 at 02:36:55PM +0300, Boaz Harrosh wrote:
> > +	/*
> > +	 * Use the session max response size as the basis for setting
> > +	 * GETDEVICEINFO's maxcount
> > +	 */
> > +	max_resp_sz = server->nfs_client->cl_session->fc_attrs.max_resp_sz;
> > +	max_pages = nfs_page_array_len(0, max_resp_sz);
> > +	dprintk("%s: server %p max_resp_sz %u max_pages %d\n",
> > +		__func__, server, max_resp_sz, max_pages);
> > +
> 
> This is an extremely too big an allocation for obj-lo (which has
> a couple of embedded strings here). The all RPC can fit a single
> page
> 
> Should we put like a flag in struct pnfs_layoutdriver_type:
> 
> 	if (server->pnfs_curr_ld->flags & PNFS_DEVINFO_SINGLE_PAGE) {
> 		max_pages = 1;
> 		max_resp_sz = PAGE_SIZE;
> 	}
> 
> This gives us so many extra allocation for storing one page pointer but for
> the simplicity of the cleanup we can live with it.

Sounds fine to me, but do you really have that many GETDEVICEINFO calls
in object layout setups that it's worth the effort?

Another slightly cleaner option would be to have a max_deviceinfo_size
field in the layout driver and cap the size by it.


  reply	other threads:[~2014-08-12 12:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 20:06 pnfs: factor GETDEVICEINFO implementations Christoph Hellwig
2014-08-11 20:06 ` [PATCH 1/4] " Christoph Hellwig
2014-08-12 11:36   ` Boaz Harrosh
2014-08-12 12:21     ` Christoph Hellwig [this message]
2014-08-12 12:33       ` Boaz Harrosh
2014-08-12 15:53       ` Christoph Hellwig
2014-08-21 14:46     ` Christoph Hellwig
2014-08-21 16:39       ` Boaz Harrosh
2014-08-11 20:06 ` [PATCH 2/4] pnfs add a common GETDEVICELIST implementation Christoph Hellwig
2014-08-11 20:06 ` [PATCH 3/4] pnfs: add a nfs4_get_deviceid helper Christoph Hellwig
2014-08-11 20:06 ` [PATCH 4/4] pnfs/blocklayout: use the device id cache Christoph Hellwig
2014-08-12  9:35 ` pnfs: factor GETDEVICEINFO implementations Boaz Harrosh
2014-08-12  9:52   ` Christoph Hellwig
2014-08-12 10:57     ` Boaz Harrosh
2014-09-03  4:27 pnfs: factor GETDEVICEINFO implementations V2 Christoph Hellwig
2014-09-03  4:27 ` [PATCH 1/4] pnfs: factor GETDEVICEINFO implementations Christoph Hellwig

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=20140812122156.GA16362@lst.de \
    --to=hch@lst.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=openosd@gmail.com \
    /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.