<div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">07.01.2019, 18:06, "Sean Mooney" <smooney@redhat.com>:</div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><p>On Mon, <span>2019-01-07</span> at 16:23 +0800, rui zang wrote:</p><blockquote> Hey Jay,<br /><br /> I replied to your comments to the spec however missed this email.<br /> Please see my replies in line.<br /><br /> Thanks,<br /> Zang, Rui<br /><br /><br /><br /> 03.01.2019, 21:31, "Jay Pipes" <<a rel="noopener noreferrer" href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>:<br /> > On 01/02/2019 11:08 PM, Alex Xu wrote:<br /> > > Jay Pipes <<a rel="noopener noreferrer" href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a> <mailto:<a rel="noopener noreferrer" href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>> 于2019年1月2<br /> > > 日周三 下午10:48写道：<br /> > ><br /> > > On 12/21/2018 03:45 AM, Rui Zang wrote:<br /> > > > It was advised in today's nova team meeting to bring this up by<br /> > > email.<br /> > > ><br /> > > > There has been some discussion on the how to track persistent memory<br /> > > > resource in placement on the spec review [1].<br /> > > ><br /> > > > Background: persistent memory (PMEM) needs to be partitioned to<br /> > > > namespaces to be consumed by VMs. Due to fragmentation issues,<br /> > > the spec<br /> > > > proposed to use fixed sized PMEM namespaces.<br /> > ><br /> > > The spec proposed to use fixed sized namespaces that is controllable by<br /> > > the deployer, not fixed-size-for-everyone :) Just want to make sure<br /> > > we're being clear here.<br /> > ><br /> > > > The spec proposed way to represent PMEM namespaces is to use one<br /> > > > Resource Provider (RP) for one PMEM namespace. An new standard<br /> > > Resource<br /> > > > Class (RC) -- 'VPMEM_GB` is introduced to classify PMEM namspace<br /> > > RPs.<br /> > > > For each PMEM namespace RP, the values for 'max_unit', 'min_unit',<br /> > > > 'total' and 'step_size` are all set to the size of the PMEM<br /> > > namespace.<br /> > > > In this way, it is guaranteed each RP will be consumed as a whole<br /> > > at one<br /> > > > time.<br /> > > ><br /> > > > An alternative was brought out in the review. Different Custom<br /> > > Resource<br /> > > > Classes ( CUSTOM_PMEM_XXXGB) can be used to designate PMEM<br /> > > namespaces of<br /> > > > different sizes. The size of the PMEM namespace is encoded in the<br /> > > name<br /> > > > of the custom Resource Class. And multiple PMEM namespaces of the<br /> > > same<br /> > > > size (say 128G) can be represented by one RP of the same<br /> > ><br /> > > Not represented by "one RP of the same CUSTOM_PMEM_128G". There<br /> > > would be<br /> > > only one resource provider: the compute node itself. It would have an<br /> > > inventory of, say, 8 CUSTOM_PMEM_128G resources.<br /> > ><br /> > > > CUSTOM_PMEM_128G. In this way, the RP could have 'max_unit' and<br /> > > 'total'<br /> > > > as the total number of the PMEM namespaces of the certain size.<br /> > > And the<br /> > > > values of 'min_unit' and 'step_size' could set to 1.<br /> > ><br /> > > No, the max_unit, min_unit, step_size and total would refer to the<br /> > > number of *PMEM namespaces*, not the amount of GB of memory represented<br /> > > by those namespaces.<br /> > ><br /> > > Therefore, min_unit and step_size would be 1, max_unit would be the<br /> > > total number of *namespaces* that could simultaneously be attached to a<br /> > > single consumer (VM), and total would be 8 in our example where the<br /> > > compute node had 8 of these pre-defined 128G PMEM namespaces.<br /> > ><br /> > > > We believe both way could work. We would like to have a community<br /> > > > consensus on which way to use.<br /> > > > Email replies and review comments to the spec [1] are both welcomed.<br /> > ><br /> > > Custom resource classes were invented for precisely this kind of use<br /> > > case. The resource being represented is a namespace. The resource is<br /> > > not<br /> > > "a Gibibyte of persistent memory".<br /> > ><br /> > ><br /> > > The point of the initial design is avoid to encode the `size` in the<br /> > > resource class name. If that is ok for you(I remember people hate to<br /> > > encode size and number into the trait name), then we will update the<br /> > > design. Probably based on the namespace configuration, nova will be<br /> > > responsible for create those custom RC first. Sounds works.<br /> ><br /> > A couple points...<br /> ><br /> > 1) I was/am opposed to putting the least-fine-grained size in a resource<br /> > class name. For example, I would have preferred DISK_BYTE instead of<br /> > DISK_GB. And MEMORY_BYTE instead of MEMORY_MB.<br /><br /> I agree the more precise the better as far as resource tracking is concerned.<br /> However, as for persistent memory, it usually comes out in large capacity --<br /> terabytes are normal. And the targeting applications are also expected to use<br /> persistent memory in that quantity. GB is a reasonable unit not to make<br /> the number too nasty.</blockquote><p><br />so im honestly not that concernetd with large numbers.<br />if we want to imporve the user experience we can do what we do with hugepage memory.<br />we suppport passing a sufix. so we can say 2M or 1G.<br /><br />if you are concerned with capasity its a relitivly simple exerises to show that if<br />we use a 64 int or even 48bit we have plenty of headroom over where teh technology is.<br /><br />NVDIMs are speced for a max capasity of 512GB per module.<br />if i recall correctly you can also only have 12 nvdim with 4 ram dimms per socket<br />acting as a cache so that effectivly limits you to 6TB per socket or 12 TB per 1/2U<br />with standard density servers. moderen x86 processors i belive still use a 48 bit<br />phyical adress spaces with the last 16 bits reserved for future use meaning a host<br />can adress a maxium of 2^48 or 256 TiB of memory such a system.<br /><br />note persistent memory is stream memory so it base 2 not base 10 so when<br />we state it 1GB we technically mean 1 GiB or 2^10 bytes not 10^9 bytes<br /><br />whiile it unlikely we will ever need byte level granularity in allocations<br />to guest im not sure i buy the argument that this will only be used by applications<br />in large allocations in the 100GB or TBs range.<br /><br />i think i share jays preference here in increasing the granularity and eiter tracking<br />the allocation in MiBs or Bytes. i do somewhat agree that bytes is likely to fine grained<br />hence my perference for mebibytes.<br /> </p></blockquote><div xmlns="http://www.w3.org/1999/xhtml">OK, I don't think we need to be better fine grained than memory (currently tracked by MB) :)</div><div xmlns="http://www.w3.org/1999/xhtml">So will change to accept a unit -- be it "TB", "GB" or "MB".</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><blockquote><br /> > 2) After reading the original Intel PMEM specification<br /> > (<a rel="noopener noreferrer" href="http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf">http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf</a>), it seems to me<br /> > that what you are describing with a generic PMEM_GB (or PMEM_BYTE)<br /> > resource class is more appropriate for the block mode translation system<br /> > described in the PDF versus the PMEM namespace system described therein.<br /> ><br /> > From a lay person's perspective, I see the difference between the two<br /> > as similar to the difference between describing the bytes that are in<br /> > block storage versus a filesystem that has been formatted, wiped,<br /> > cleaned, etc on that block storage.<br /><br /> First let's talk about "block mode" v.s. "persistent memory mode".<br /> They are not tiered up, they are counterparts. Each of them describes an access<br /> method to the unlerlying hardware. Quote some sectors from<br /> <a rel="noopener noreferrer" href="https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt">https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt</a><br /> inside the dash line block.<br /><br /> ------------------------------8<-------------------------------------------------------------------<br /> Why BLK?<br /> --------<br /><br /> While PMEM provides direct byte-addressable CPU-load/store access to<br /> NVDIMM storage, it does not provide the best system RAS (recovery,<br /> availability, and serviceability) model. An access to a corrupted<br /> system-physical-address address causes a CPU exception while an access<br /> to a corrupted address through an BLK-aperture causes that block window<br /> to raise an error status in a register. The latter is more aligned with<br /> the standard error model that host-bus-adapter attached disks present.<br /> Also, if an administrator ever wants to replace a memory it is easier to<br /> service a system at DIMM module boundaries. Compare this to PMEM where<br /> data could be interleaved in an opaque hardware specific manner across<br /> several DIMMs.<br /><br /> PMEM vs BLK<br /> BLK-apertures solve these RAS problems, but their presence is also the<br /> major contributing factor to the complexity of the ND subsystem. They<br /> complicate the implementation because PMEM and BLK alias in DPA space.<br /> Any given DIMM's DPA-range may contribute to one or more<br /> system-physical-address sets of interleaved DIMMs, *and* may also be<br /> accessed in its entirety through its BLK-aperture. Accessing a DPA<br /> through a system-physical-address while simultaneously accessing the<br /> same DPA through a BLK-aperture has undefined results. For this reason,<br /> DIMMs with this dual interface configuration include a DSM function to<br /> store/retrieve a LABEL. The LABEL effectively partitions the DPA-space<br /> into exclusive system-physical-address and BLK-aperture accessible<br /> regions. For simplicity a DIMM is allowed a PMEM "region" per each<br /> interleave set in which it is a member. The remaining DPA space can be<br /> carved into an arbitrary number of BLK devices with discontiguous<br /> extents.<br /> ------------------------------8<-------------------------------------------------------------------<br /><br /> You can see that "block mode" does not provide "direct access", thus not the best<br /> performance. That is the reason "persistent memory mode" is proposed in the spec.</blockquote><p>the block mode will allow any exsing applciation that is coded to work with a block device<br />to just use the NVDIM storage as a faster from of solid state storage. direct mode reqiures<br />applications to be specifcialy coded to support it. form an openstack perspective we will<br />eventually want to support exposing the deivce both as a block deivce (e.g. via virtio-blk or virtio-scsi devices<br />if/when qemu supports that) and direct mode pmem device to the guest. i understand why persistent memory mode is more<br />appealing from a vendor perspecitve to lead with but pratically speaking there are very few application that actully<br />supprot pmem to date and supporting app direct mode only seams like it would hurt adoption of this feautre<br />more generally then encourage it.</p></blockquote><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Hey Sean, as I mentioned, you can also get a block device and file system out of the direct mode (pmem in the terms I choose to use).</div><div xmlns="http://www.w3.org/1999/xhtml">Yes, I agree block mode has its advantages in RAS. However currently QEMU only virtualizes direct mode in guests even being backed by a device in block mode ... and I am sure people have different interpretations on that fact :)</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><blockquote><br /> However, people can still create a block device out of a "persistent memory mode"<br /> namespace. And further more, create a file system on top of that block device.<br /> Applications can map files from that file system into their memory namespaces,<br /> and if the file system is DAX (direct-access) capable. The application's access to<br /> the hardware is still direct-access which means direct byte-addressable<br /> CPU-load/store access to NVDIMM storage.<br /> This is perfect so far, as one can think of why not just track the DAX file system<br /> and let the VM instances map the files of the file system?<br /> However, this usage model is reported to have severe issues with hardware<br /> pass-ed through. So the recommended model is still mapping namespaces<br /> of "persistent memory mode" into applications' address space.<br /> </blockquote><p><br />intels nvdimm technology works in 3 modes, app direct, block and system memory.</p></blockquote><div xmlns="http://www.w3.org/1999/xhtml">Yes, nvdimm is hidden in system memory mode.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><p>the direct and block modes were discussed at some lenght in the spec and this thread.<br />does libvirt support using a nvdims pmem namespaces in devdax mode to back a guest memory<br />instead of system ram.<br /><br />based on <a rel="noopener noreferrer" href="https://docs.pmem.io/getting-started-guide/creating-development-environments/virtualization/qemu">https://docs.pmem.io/getting-started-guide/creating-development-environments/virtualization/qemu</a><br />qemu does support such a configuration and honestly haveing the capablity to alter the guest meory<br />backing to run my vms with 100s or GB of ram would as compeeling as app direct mode as<br />it would allow all my legacy application to work without modification and would deliver effectivly the same<br />perfromance. perhaps we should also consider a hw:mem_page_backing extra spec to complement the hw:mem_page_size<br />we have already hugepages today. this would proably be a seperate spec but i would hope we dont make desisions<br />today that would block other useage models in the future.</p></blockquote><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Yes, exactly. We have other usage model as you mentioned in pipeline.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><blockquote><br /><br /><br /> > In Nova, the DISK_GB resource class describes the former: it's a bunch<br /> > of blocks that are reserved in the underlying block storage for use by<br /> > the virtual machine. The virtual machine manager then formats that bunch<br /> > of blocks as needed and lays down a formatted image.<br /> ><br /> > We don't have a resource class that represents "a filesystem" or "a<br /> > partition" (yet). But the proposed PMEM namespaces in your spec<br /> > definitely seem to be more like a "filesystem resource" than a "GB of<br /> > block storage" resource.<br /> ><br /> > Best,<br /> > -jay</blockquote><p> </p></blockquote>