On Thu, Jul 29, 2021 at 10:06:16PM +0200, David Hildenbrand wrote:
> On 29.07.21 22:00, Peter Xu wrote:
> > On Thu, Jul 29, 2021 at 09:39:24PM +0200, David Hildenbrand wrote:
> > >
> > > > > In the meantime I adjusted the code but it does the clearing under the
> > > > > iothread lock, which shoul
On 29.07.21 22:00, Peter Xu wrote:
On Thu, Jul 29, 2021 at 09:39:24PM +0200, David Hildenbrand wrote:
In the meantime I adjusted the code but it does the clearing under the
iothread lock, which should not be what we want ... I'll have a look.
Thanks; if it takes more changes than expected we
On Thu, Jul 29, 2021 at 09:39:24PM +0200, David Hildenbrand wrote:
>
> > > In the meantime I adjusted the code but it does the clearing under the
> > > iothread lock, which should not be what we want ... I'll have a look.
> >
> > Thanks; if it takes more changes than expected we can still start f
In the meantime I adjusted the code but it does the clearing under the
iothread lock, which should not be what we want ... I'll have a look.
Thanks; if it takes more changes than expected we can still start from simple,
IMHO, by taking bql and timely yield it.
At the meantime, I found two th
On Thu, Jul 29, 2021 at 06:19:31PM +0200, David Hildenbrand wrote:
> On 29.07.21 18:12, Peter Xu wrote:
> > On Thu, Jul 29, 2021 at 10:14:47AM +0200, David Hildenbrand wrote:
> > > > > > > > The thing is I still think this extra operation during sync()
> > > > > > > > can be ignored by
> > > > > >
On 29.07.21 18:12, Peter Xu wrote:
On Thu, Jul 29, 2021 at 10:14:47AM +0200, David Hildenbrand wrote:
The thing is I still think this extra operation during sync() can be ignored by
simply clear dirty log during bitmap init, then.. why not? :)
I guess clearing the dirty log (especially in KVM)
On Thu, Jul 29, 2021 at 10:14:47AM +0200, David Hildenbrand wrote:
> > > > > > The thing is I still think this extra operation during sync() can
> > > > > > be ignored by
> > > > > > simply clear dirty log during bitmap init, then.. why not? :)
> > > > >
> > > > > I guess clearing the dirty log (
The thing is I still think this extra operation during sync() can be ignored by
simply clear dirty log during bitmap init, then.. why not? :)
I guess clearing the dirty log (especially in KVM) might be more expensive.
If we send one ioctl per cb that'll be expensive for sure. I think it'll be
On Wed, Jul 28, 2021 at 09:46:09PM +0200, David Hildenbrand wrote:
> On 28.07.21 21:42, Peter Xu wrote:
> > On Wed, Jul 28, 2021 at 07:39:39PM +0200, David Hildenbrand wrote:
> > > > Meanwhile, I still have no idea how much overhead the "loop" part could
> > > > bring.
> > > > For a large virtio-m
On 28.07.21 21:42, Peter Xu wrote:
On Wed, Jul 28, 2021 at 07:39:39PM +0200, David Hildenbrand wrote:
Meanwhile, I still have no idea how much overhead the "loop" part could bring.
For a large virtio-mem region with frequent plugged/unplugged mem interacted,
it seems possible to take a while to
On Wed, Jul 28, 2021 at 07:39:39PM +0200, David Hildenbrand wrote:
> > Meanwhile, I still have no idea how much overhead the "loop" part could
> > bring.
> > For a large virtio-mem region with frequent plugged/unplugged mem
> > interacted,
> > it seems possible to take a while to me.. I have no
On 27.07.21 19:10, Peter Xu wrote:
On Tue, Jul 27, 2021 at 11:25:09AM +0200, David Hildenbrand wrote:
For 2) I see 3 options:
a) Sync everything, fixup the dirty bitmap, never clear the dirty log of
discarded parts. It's fairly simple and straight forward, as I can simply
reuse the existing hel
On Tue, Jul 27, 2021 at 11:25:09AM +0200, David Hildenbrand wrote:
> For 2) I see 3 options:
>
> a) Sync everything, fixup the dirty bitmap, never clear the dirty log of
> discarded parts. It's fairly simple and straight forward, as I can simply
> reuse the existing helper. Something that's discar
On 24.07.21 00:19, Peter Xu wrote:
On Fri, Jul 23, 2021 at 08:41:40PM +0200, David Hildenbrand wrote:
On 23.07.21 18:12, Peter Xu wrote:
On Thu, Jul 22, 2021 at 01:43:41PM +0200, David Hildenbrand wrote:
a) In precopy code, always clearing all dirty bits from the bitmap that
correspond t
On Fri, Jul 23, 2021 at 08:41:40PM +0200, David Hildenbrand wrote:
> On 23.07.21 18:12, Peter Xu wrote:
> > On Thu, Jul 22, 2021 at 01:43:41PM +0200, David Hildenbrand wrote:
> > > > > a) In precopy code, always clearing all dirty bits from the bitmap
> > > > > that
> > > > > correspond to di
On 23.07.21 18:12, Peter Xu wrote:
On Thu, Jul 22, 2021 at 01:43:41PM +0200, David Hildenbrand wrote:
a) In precopy code, always clearing all dirty bits from the bitmap that
correspond to discarded range, whenever we update the dirty bitmap. This
results in logically unplugged memory t
On Thu, Jul 22, 2021 at 01:43:41PM +0200, David Hildenbrand wrote:
> > > a) In precopy code, always clearing all dirty bits from the bitmap that
> > > correspond to discarded range, whenever we update the dirty bitmap.
> > > This
> > > results in logically unplugged memory to never get mig
On 22.07.21 13:29, Dr. David Alan Gilbert wrote:
* David Hildenbrand (da...@redhat.com) wrote:
virtio-mem exposes a dynamic amount of memory within RAMBlocks by
coordinating with the VM. Memory within a RAMBlock can either get
plugged and consequently used by the VM, or unplugged and consequentl
* David Hildenbrand (da...@redhat.com) wrote:
> virtio-mem exposes a dynamic amount of memory within RAMBlocks by
> coordinating with the VM. Memory within a RAMBlock can either get
> plugged and consequently used by the VM, or unplugged and consequently no
> longer used by the VM. Logical unplug i
virtio-mem exposes a dynamic amount of memory within RAMBlocks by
coordinating with the VM. Memory within a RAMBlock can either get
plugged and consequently used by the VM, or unplugged and consequently no
longer used by the VM. Logical unplug is realized by discarding the
physical memory backing f
20 matches
Mail list logo
