public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sjpark@amazon.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	SeongJae Park <sjpark@amazon.com>,
	SeongJae Park <sjpark@amazon.de>, <axboe@kernel.dk>,
	<aliguori@amazon.com>, <amit@kernel.org>, <mheyne@amazon.de>,
	<linux-block@vger.kernel.org>, <xen-devel@lists.xenproject.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xen-blkback: add a parameter for disabling of persistent grants
Date: Thu, 24 Sep 2020 12:27:14 +0200	[thread overview]
Message-ID: <20200924102714.28141-1-sjpark@amazon.com> (raw)
In-Reply-To: <20200924101344.GN19254@Air-de-Roger>

On Thu, 24 Sep 2020 12:13:44 +0200 "Roger Pau Monné" <roger.pau@citrix.com> wrote:

> On Wed, Sep 23, 2020 at 04:09:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> > > From: SeongJae Park <sjpark@amazon.de>
> > > 
> > > Persistent grants feature provides high scalability.  On some small
> > > systems, however, it could incur data copy overhead[1] and thus it is
> > > required to be disabled.  But, there is no option to disable it.  For
> > > the reason, this commit adds a module parameter for disabling of the
> > > feature.
> > 
> > Would it be better suited to have it per guest?
> 
> I think having a per-backend policy that could be specified at the
> toolstack level would be nice, but I see that as a further
> improvement.

Agreed.

> 
> Having a global backend domain policy of whether persistent grants are
> enabled or not seems desirable, and if someone wants even more fine
> grained control this change is AFAICT not incompatible with a
> per-backend option anyway.

I think we could extend this design by receiving list of exceptional domains.
For example, if 'feature_persistent' is True and exceptions list has '123,
456', domains of domid 123 and 456 will not use persistent grants, and vice
versa.

I could implement this, but... to be honest, I don't really understand the
needs of the fine-grained control.  AFAIU, the problem is 'scalability' vs
'data copy overhead'.  So, only small systems would want to turn persistent
grants off.  In such a small system, why would we need fine-grained control?
I'm worrying if I would implement and maintain a feature without real use case.

For the reason, I'd like to suggest to keep this as is for now and expand it
with the 'exceptions list' idea or something better, if a real use case comes
out later.


Thanks,
SeongJae Park

  reply	other threads:[~2020-09-24 10:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  7:01 [PATCH] xen-blkback: add a parameter for disabling of persistent grants SeongJae Park
2020-09-22  7:18 ` Jürgen Groß
2020-09-22  7:24   ` SeongJae Park
2020-09-22  7:32 ` Roger Pau Monné
2020-09-22  7:57   ` SeongJae Park
2020-09-23 20:09 ` Konrad Rzeszutek Wilk
2020-09-24  6:26   ` SeongJae Park
2020-09-24 10:13   ` Roger Pau Monné
2020-09-24 10:27     ` SeongJae Park [this message]
2020-09-24 10:47       ` Roger Pau Monné
2020-09-24 15:59         ` Konrad Rzeszutek Wilk

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=20200924102714.28141-1-sjpark@amazon.com \
    --to=sjpark@amazon.com \
    --cc=aliguori@amazon.com \
    --cc=amit@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mheyne@amazon.de \
    --cc=roger.pau@citrix.com \
    --cc=sjpark@amazon.de \
    --cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox