From: Bob Liu <bob.liu@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
konrad.wilk@oracle.com, jgross@suse.com
Subject: Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources
Date: Fri, 22 Jul 2016 16:17:48 +0800 [thread overview]
Message-ID: <5791D6AC.1070604@oracle.com> (raw)
In-Reply-To: <20160722074506.l5nfcmqg3jzsmxzi@mac>
On 07/22/2016 03:45 PM, Roger Pau Monné wrote:
> On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote:
>>
>> On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
..[snip]..
>>>> +
>>>> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t count)
>>>> +{
>>>> + unsigned int i;
>>>> + int err = -EBUSY;
>>>> +
>>>> + /*
>>>> + * Make sure no migration in parallel, device lock is actually a
>>>> + * mutex.
>>>> + */
>>>> + if (!device_trylock(&info->xbdev->dev)) {
>>>> + pr_err("Fail to acquire dev:%s lock, may be in migration.\n",
>>>> + dev_name(&info->xbdev->dev));
>>>> + return err;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Prevent new requests and guarantee no uncompleted reqs.
>>>> + */
>>>> + blk_mq_freeze_queue(info->rq);
>>>> + if (part_in_flight(&info->gd->part0))
>>>> + goto out;
>>>> +
>>>> + /*
>>>> + * Front Backend
>>>> + * Switch to XenbusStateClosed
>>>> + * frontend_changed():
>>>> + * case XenbusStateClosed:
>>>> + * xen_blkif_disconnect()
>>>> + * Switch to XenbusStateClosed
>>>> + * blkfront_resume():
>>>> + * frontend_changed():
>>>> + * reconnect
>>>> + * Wait until XenbusStateConnected
>>>> + */
>>>> + info->reconfiguring = true;
>>>> + xenbus_switch_state(info->xbdev, XenbusStateClosed);
>>>> +
>>>> + /* Poll every 100ms, 1 minute timeout. */
>>>> + for (i = 0; i < 600; i++) {
>>>> + /*
>>>> + * Wait backend enter XenbusStateClosed, blkback_changed()
>>>> + * will clear reconfiguring.
>>>> + */
>>>> + if (!info->reconfiguring)
>>>> + goto resume;
>>>> + schedule_timeout_interruptible(msecs_to_jiffies(100));
>>>> + }
>>>
>>> Instead of having this wait, could you just set info->reconfiguring = 1, set
>>> the frontend state to XenbusStateClosed and mimic exactly what a resume from
>>> suspension does? blkback_changed would have to set the frontend state to
>>> InitWait when it detects that the backend has switched to Closed, and call
>>> blkfront_resume.
>>
>>
>> I think that won't work.
>> In the real "resume" case, the power management system will trigger all ->resume() path.
>> But there is no place for dynamic configuration.
>
> Hello,
>
> I think it should be possible to set info->reconfiguring and wait for the
> backend to switch to state Closed, at that point we should call blkif_resume
> (from blkback_changed) and the backend will follow the reconection.
>
Okay, I get your point. Yes, that's an option.
But this will make 'dynamic configuration' to be async, I'm worry about the end-user will get panic.
E.g
A end-user "echo <new value> > /sys/devices/vbd-xxx/max_indirect_segs",
but then the device will be Closed and disappeared, the user have to wait for a random time so that the device can resume.
--
Regards,
-Bob
next prev parent reply other threads:[~2016-07-22 8:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 9:31 [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity Bob Liu
2016-07-15 9:31 ` [PATCH 2/3] xen-blkfront: introduce blkif_set_queue_limits() Bob Liu
2016-07-21 8:29 ` Roger Pau Monné
2016-07-21 9:44 ` Bob Liu
2016-07-15 9:31 ` [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources Bob Liu
2016-07-21 8:57 ` Roger Pau Monné
2016-07-21 10:08 ` Bob Liu
2016-07-22 7:45 ` Roger Pau Monné
2016-07-22 8:17 ` Bob Liu [this message]
2016-07-22 9:34 ` Roger Pau Monné
2016-07-22 9:43 ` Bob Liu
2016-07-22 11:45 ` Roger Pau Monné
2016-07-22 22:18 ` Bob Liu
2016-07-25 9:20 ` Roger Pau Monné
2016-07-25 10:29 ` Bob Liu
2016-07-25 10:53 ` Roger Pau Monné
2016-07-25 11:08 ` Bob Liu
2016-07-25 12:11 ` Roger Pau Monné
2016-07-25 12:25 ` Bob Liu
2016-07-21 8:06 ` [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity Roger Pau Monné
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=5791D6AC.1070604@oracle.com \
--to=bob.liu@oracle.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roger.pau@citrix.com \
--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;
as well as URLs for NNTP newsgroup(s).