[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v5 0/2] virtio-fs: add virtio file system device
On Fri, Jul 26, 2019 at 01:34:16PM +0100, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (mst@redhat.com) wrote: > > Didn't look at the spec yet, but I have a question: > > > > On Fri, Jul 26, 2019 at 10:53:36AM +0100, Stefan Hajnoczi wrote: > > > v5: > > > * Explain multiqueue semantics: no ordering, identical functionality on each queue, one FUSE session state shared between all queues > > > * Explain how the FUSE session is started with a FUSE_INIT request > > > * Consistently use "submit" vs "made available" and "complete" vs "used" terminology [Michael] > > > * Explain endianness [Michael] > > > * Clarify hiprio vs normal queue usage [Michael] > > > * Move SHOULD, MUST, etc wording into normative sections [Michael] > > > * Mention that FUSE_INIT negotiated state needs to be transferred during live migration [Michael] > > > * State that the DAX window is mapped with writeback caching like RAM [Michael] > > > * Mention DAX window mapping alignment constraints (they are communicated via the FUSE protocol) [Michael] > > > * Explain that FUSE_SETUPMAPPING fails when device resources are exhausted and that splitting mappings consumes resources too [Michael] > > > * Clarify access rules to DAX window - only touch memory that has a mapping establised > > > * Document that DAX data persistence is achieved via FUSE_FSYNC > > > > > > The following was raised during v4 review: > > > > > > > > There is a practical problem that the QEMU process may hit the mmap > > > > > > limit and be unable to perform its own mmaps due to the DAX Window. A > > > > > > limit must be enforced on the host so that QEMU's internal mmaps > > > > > > succeed. > > > > > > > > > > But number of mmaps are already limited by dax window size which is > > > > > controlled by virtiofsd. So all user has to do is start with smaller > > > > > dax window size if this ever becomes a concern. > > > > > > > > Yes, the DAX Window size sets a hard limit on the number of mappings > > > > (window_size / page_size). I think we should still communicate a > > > > maximum number of mappings to provide more control for cases where the > > > > page size and DAX Window size don't produce a desirable number. > > > > > > > > Consider that window_size = 8 GB and page_size = 4 KB already yields > > > > 2,097,152 maximum mappings. Oops, that number is too large! > > > > > > Ok, so that's something which will be in virtiofsd where maximum number > > > of outstanding can be configured by user and if we cross that limit, > > > FUSE_SETUPMAPPING will be returned with some error? > > > > Yes, virtiofsd will enforce the limit. > > > > The guest driver will also be aware of the limit via VIRTIO > > configuration space. > > > > was this addressed? > > In this version Stefan has marked SETUPMAPPING to say it can fail if out > of resources. > > The tricky problem with specifying a limit is that the limit is more > likely to be global than to be per-device, and so specifying it in > either the virtio config space or (as looked more appropriate) fuse init > doesn't feel right. > > IMHO we should never hit the limit in practical use, so it's really just > a matter of saying that it can fail and setting a large enough limit > that non-abusive drivers dont cause a problem. Yep, I updated the spec to mention that FUSE_SETUPMAPPING fails when there are insufficient resources. Drivers expect that it can happen and will have to unmap existing mappings if they wish to make new ones. Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]