Re: [PATCH v3 2/3] spapr: nvdimm: Implement H_SCM_FLUSH hcall

[Shivaprasad G Bhat]

On 3/24/21 8:37 AM, David Gibson wrote:

> On Tue, Mar 23, 2021 at 09:47:38AM -0400, Shivaprasad G Bhat wrote:
> > machine vmstate.
> >
> > Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> >       
> An overal question: surely the same issue must arise on x86 with
> file-backed NVDIMMs.  How do they handle this case?
>

Discussed in other threads..

....

> >  };
> > @@ -2997,6 +3000,9 @@ static void spapr_machine_init(MachineState *machine)
> >      }
> >  
> >      qemu_cond_init(&spapr->fwnmi_machine_check_interlock_cond);
> > +    qemu_mutex_init(&spapr->spapr_nvdimm_flush_states_lock);
> >       
> Do you actually need an extra mutex, or can you rely on the BQL?
>

I verified BQL is held at all places where it matters in the context of this patch.

Safe to get rid of this extra mutex.

...

> > +{
> > +     SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > +
> > +     return (!QLIST_EMPTY(&spapr->pending_flush_states) ||
> > +             !QLIST_EMPTY(&spapr->completed_flush_states));
> > +}
> > +
> > +static int spapr_nvdimm_pre_save(void *opaque)
> > +{
> > +    SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > +
> > +    while (!QLIST_EMPTY(&spapr->pending_flush_states)) {
> > +        aio_poll(qemu_get_aio_context(), true);
> >       
> Hmm... how long could waiting for all the pending flushes to complete
> take?  This could add substanially to the guest's migration downtime,
> couldn't it?
>     


    
 The time taken depends on the number of dirtied pages and
the disk io write
speed. The number of dirty pages on host
is configureable with tunables 

vm.dirty_background_ratio
(10% default on Fedora 32, Ubuntu 20.04), 

vm.dirty_ratio(20%)
of host memory and|or vm.dirty_expire_centisecs(30 seconds).
So, the host itself would be flushing the mmaped file on its
own from time to time.


For guests using the nvdimms with filesystem, the flushes
would have come frequently and the number of dirty pages
might be less. The pmem applications can use the nvdimms
without a filesystem. And for such guests, the chances that
a flush request can come from pmem applications at the time
of migration is less or is random. But, the host would have
flushed the pagecache on its own when vm.dirty_background_ratio
is crossed or vm.dirty_expire_centisecs expired. 

So, the worst case would stands at disk io latency for writing
the dirtied pages in the last vm.dirty_expire_centisecs on host
OR latency for writing maximum vm.dirty_background_ratio(10%)
of host RAM.

If you want me to calibrate any particular size, scenario and get
the numbers please let me know.
    ...
> > +
> > +/*
> > + * Acquire a unique token and reserve it for the new flush state.
> > + */
> > +static SpaprNVDIMMDeviceFlushState *spapr_nvdimm_init_new_flush_state(void)
> > +{
> > +    Error *err = NULL;
> > +    uint64_t token;
> > +    SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > +    SpaprNVDIMMDeviceFlushState *tmp, *next, *state;
> > +
> > +    state = g_malloc0(sizeof(*state));
> > +
> > +    qemu_mutex_lock(&spapr->spapr_nvdimm_flush_states_lock);
> > +retry:
> > +    if (qemu_guest_getrandom(&token, sizeof(token), &err) < 0) {
> >       
> Using getrandom seems like overkill, why not just use a counter?
>

I didnt want a spurious guest to abuse by consuming the return value providing

a valid "guess-able" counter and the real driver failing subsequently. Also, across

guest migrations carrying the global counter to destination is another thing to ponder.

Let me know if you want me to reconsider using counter.

...

> > mm_flush_states_lock);
> > +
> > +    return state;
> > +}
> > +
> > +/*
> > + * spapr_nvdimm_finish_flushes
> > + *      Waits for all pending flush requests to complete
> > + *      their execution and free the states
> > + */
> > +void spapr_nvdimm_finish_flushes(void)
> > +{
> > +    SpaprNVDIMMDeviceFlushState *state, *next;
> > +    SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> >       
> The caller has natural access to the machine, so pass it in rather
> than using the global.
>

okay

...

> > +
> > +/*
> > + * spapr_nvdimm_get_hcall_status
> > + *      Fetches the status of the hcall worker and returns H_BUSY
> > + *      if the worker is still running.
> > + */
> > +static int spapr_nvdimm_get_flush_status(uint64_t token)
> > +{
> > +    int ret = H_LONG_BUSY_ORDER_10_MSEC;
> > +    SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> >       
> The callers have natural access to spapr, so pass it in rather than
> using the global.
>

Okay

...

> > +
> > +/*
> > + * H_SCM_FLUSH
> > + * Input: drc_index, continue-token
> > + * Out: continue-token
> > + * Return Value: H_SUCCESS, H_Parameter, H_P2, H_BUSY
> > + *
> > + * Given a DRC Index Flush the data to backend NVDIMM device.
> > + * The hcall returns H_BUSY when the flush takes longer time and the hcall
> >       
> It returns one of the H_LONG_BUSY values, not actual H_BUSY, doesn't
> it?
>

Yes. I thought its okay to call it just H_BUSY in a generic way. Will fix it.

> > + * needs to be issued multiple times in order to be completely serviced.
> > +        }
> > +
> > +        return ret;
> > +    }
> > +
> > +    dimm = PC_DIMM(drc->dev);
> > +    backend = MEMORY_BACKEND(dimm->hostmem);
> > +
> > +    state = spapr_nvdimm_init_new_flush_state();
> > +    if (!state) {
> > +        return H_P2;
> >       
> AFAICT the only way init_new_flush_state() fails is a failure in the
> RNG, which definitely isn't a parameter problem.
>

Will change it to H_HARDWARE.

> > +    }
> > +
> > +    state->backend_fd = memory_region_get_fd(&backend->mr);
> >       
> Is this guaranteed to return a usable fd in all configurations?
>

Right, for memory-backend-ram this wont work. I think we should

not set the hcall-flush-required too for memory-backend-ram. Will fix this.

> > +    thread_pool_submit_aio(pool, flush_worker_cb, state,
> > +                           spapr_nvdimm_flush_completion_cb, state);
> > +
> > +    ret = spapr_nvdimm_get_flush_status(state->continue_token);
> > +    if (H_IS_LONG_BUSY(ret)) {
> > +        args[0] = state->continue_token;
> > +    }
> > +
> > +    return ret;
> >       
> I believe you can rearrange this so the get_flush_status / check /
> return is shared between the args[0] == 0 and args[0] == token paths.
>     
    okay.
>

Thanks,

Shiva