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
signature.asc
Description: PGP signature
