search for: madvisev

...e order is the same as very large len, 6 bits of order or 8 bytes of len won't really move the needle here, simpler code is preferable. The main benefit of "len" is that it can be more granular, plus it's simpler than the bitmap too. Eventually all this stuff has to end up into a madvisev (not yet upstream but somebody posted it for jemalloc and should get merged eventually). So the bitmap shall be demuxed to a addr,len array anyway, the bitmap won't ever be sent to the madvise syscall, which makes the intermediate representation with the bitmap a complication with basically no...

Removing silly virtio-dev@ list because it's bouncing mail... On 12/07/2016 08:21 AM, David Hildenbrand wrote: >> Li's current patches do that. Well, maybe not pfn/length, but they do >> take a pfn and page-order, which fits perfectly with the kernel's >> concept of high-order pages. > > So we can send length in powers of two. Still, I don't see any

Removing silly virtio-dev@ list because it's bouncing mail... On 12/07/2016 08:21 AM, David Hildenbrand wrote: >> Li's current patches do that. Well, maybe not pfn/length, but they do >> take a pfn and page-order, which fits perfectly with the kernel's >> concept of high-order pages. > > So we can send length in powers of two. Still, I don't see any

...impler code is > preferable. Agreed. But without seeing them side-by-side I'm not sure we can say which is simpler. > The main benefit of "len" is that it can be more granular, plus it's > simpler than the bitmap too. Eventually all this stuff has to end up > into a madvisev (not yet upstream but somebody posted it for jemalloc > and should get merged eventually). > > So the bitmap shall be demuxed to a addr,len array anyway, the bitmap > won't ever be sent to the madvise syscall, which makes the > intermediate representation with the bitmap a compl...

...impler code is > preferable. Agreed. But without seeing them side-by-side I'm not sure we can say which is simpler. > The main benefit of "len" is that it can be more granular, plus it's > simpler than the bitmap too. Eventually all this stuff has to end up > into a madvisev (not yet upstream but somebody posted it for jemalloc > and should get merged eventually). > > So the bitmap shall be demuxed to a addr,len array anyway, the bitmap > won't ever be sent to the madvise syscall, which makes the > intermediate representation with the bitmap a compl...