From: David Gibson <david@gibson.dropbear.id.au>
To: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Cc: Greg Kurz <groug@kaod.org>,
xiaoguangrong.eric@gmail.com, mst@redhat.com,
imammedo@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
linux-nvdimm@lists.01.org, aneesh.kumar@linux.ibm.com,
kvm-ppc@vger.kernel.org, shivaprasadbhat@gmail.com,
bharata@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC Qemu PATCH v2 1/2] spapr: drc: Add support for async hcalls at the drc level
Date: Mon, 8 Feb 2021 17:21:22 +1100 [thread overview]
Message-ID: <20210208062122.GA40668@yekko.fritz.box> (raw)
In-Reply-To: <3b47312a-217f-8df5-0bfd-1a653598abad@linux.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1890 bytes --]
On Tue, Jan 19, 2021 at 12:40:31PM +0530, Shivaprasad G Bhat wrote:
> Thanks for the comments!
>
>
> On 12/28/20 2:08 PM, David Gibson wrote:
>
> > On Mon, Dec 21, 2020 at 01:08:53PM +0100, Greg Kurz wrote:
> ...
> > > The overall idea looks good but I think you should consider using
> > > a thread pool to implement it. See below.
> > I am not convinced, however. Specifically, attaching this to the DRC
> > doesn't make sense to me. We're adding exactly one DRC related async
> > hcall, and I can't really see much call for another one. We could
> > have other async hcalls - indeed we already have one for HPT resizing
> > - but attaching this to DRCs doesn't help for those.
>
> The semantics of the hcall made me think, if this is going to be
> re-usable for future if implemented at DRC level.
It would only be re-usable for operations that are actually connected
to DRCs. It doesn't seem to me particularly likely that we'll ever
have more asynchronous hcalls that are also associated with DRCs.
> Other option
> is to move the async-hcall-state/list into the NVDIMMState structure
> in include/hw/mem/nvdimm.h and handle it with machine->nvdimms_state
> at a global level.
I'm ok with either of two options:
A) Implement this ad-hoc for this specific case, making whatever
simplifications you can based on this specific case.
B) Implement a general mechanism for async hcalls that is *not* tied
to DRCs. Then use that for the existing H_RESIZE_HPT_PREPARE call as
well as this new one.
> Hope you are okay with using the pool based approach that Greg
Honestly a thread pool seems like it might be overkill for this
application.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2021-02-08 6:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 15:16 [RFC Qemu PATCH v2 0/2] spapr: nvdimm: Asynchronus flush hcall support Shivaprasad G Bhat
2020-11-30 15:16 ` [RFC Qemu PATCH v2 1/2] spapr: drc: Add support for async hcalls at the drc level Shivaprasad G Bhat
2020-12-21 12:08 ` Greg Kurz
2020-12-21 14:37 ` Greg Kurz
2020-12-28 8:38 ` David Gibson
2021-01-19 7:10 ` Shivaprasad G Bhat
2021-02-08 6:21 ` David Gibson [this message]
2021-03-23 7:53 ` Shivaprasad G Bhat
2020-11-30 15:17 ` [RFC Qemu PATCH v2 2/2] spapr: nvdimm: Implement async flush hcalls Shivaprasad G Bhat
2020-12-21 13:07 ` Greg Kurz
2020-12-21 13:07 ` [RFC Qemu PATCH v2 0/2] spapr: nvdimm: Asynchronus flush hcall support Greg Kurz
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=20210208062122.GA40668@yekko.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aneesh.kumar@linux.ibm.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sbhat@linux.ibm.com \
--cc=shivaprasadbhat@gmail.com \
--cc=xiaoguangrong.eric@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 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).