OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [PATCH v3 6/8] admin: Add theory of operation for write recording commands


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, November 16, 2023 10:56 PM
> 
> On Thu, Nov 16, 2023 at 04:26:53PM +0000, Parav Pandit wrote:
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Thursday, November 16, 2023 5:18 PM
> > >
> > > On Thu, Nov 16, 2023 at 07:40:57AM +0000, Parav Pandit wrote:
> > > >
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Thursday, November 16, 2023 1:06 PM
> > > > >
> > > > > On Thu, Nov 16, 2023 at 12:51:40AM -0500, Michael S. Tsirkin wrote:
> > > > > > On Thu, Nov 16, 2023 at 05:29:54AM +0000, Parav Pandit wrote:
> > > > > > > We should expose a limit of the device in the proposed
> > > > > WRITE_RECORD_CAP_QUERY command, that how much range it can
> track.
> > > > > > > So that future provisioning framework can use it.
> > > > > > >
> > > > > > > I will cover this in v5 early next week.
> > > > > >
> > > > > > I do worry about how this can even work though. If you want a
> > > > > > generic device you do not get to dictate how much memory VM has.
> > > > > >
> > > > > > Aren't we talking bit per page? With 1TByte of memory to track
> > > > > > -> 256Gbit -> 32Gbit -> 8Gbyte per VF?
> > > > >
> > > > > Ugh. Actually of course:
> > > > > With 1TByte of memory to track -> 256Mbit -> 32Mbit -> 8Mbyte
> > > > > per VF
> > > > >
> > > > > 8Gbyte per *PF* with 1K VFs.
> > > > >
> > > > Device may not maintain as a bitmap.
> > >
> > > However you maintain it, there's 256Mega bit of information.
> > There may be other data structures that device may deploy as for example
> hash or tree or something else.
> 
> Point being?
The device may have some hashing accelerator or other improvements that may perform better than bitmap as many queues in parallel attempt to update the shared database.

> 
> > And this is runtime memory only during the short live migration period of
> 400msec or less.
> > It is not some _always_ resident memory.
> 
> No - write tracking is used in the live phase of migration. It can be enabled as
> long as you wish - it's a question of policy.  There actually exist solutions that
> utilize this phase for redundancy, permanently running in this mode.

If such use case exists, one may further improve the device implementation.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]