Re: [PATCH v5] drivers/misc: vm_gen_counter: initial driver implementation

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Mar 15, 2018 at 02:19:59PM +0100, Greg KH wrote:
> On Wed, Mar 14, 2018 at 09:25:17PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 14, 2018 at 07:25:36PM +0100, Greg KH wrote:
> > > On Tue, Mar 13, 2018 at 07:40:51PM +0200, Michael S. Tsirkin wrote:
> > > > I think it's a good idea to use sysfs for this. However,
> > > > there are a couple of missing interfaces here:
> > > > 
> > > > 1. Userspace needs a way to know when this value changes.
> > > >    I see no change notifications here and that does not seem right.
> > > 
> > > How can these change?
> > 
> > It's a hardware register. It changes when hardware feels like it :)
> 
> Does the hardware notify the kernel that it changes?  Or does the kernel
> have to "poll" for it?

Yes - it sends an ACPI interrupt notification.

> > In particular, it changes whenever VM is migrated or snapshotted.
> 
> So very rarely.  And userspace always knows about those events already,
> right?

Not at all.

> > > > 2. Userspace needs to be able to read these without
> > > >    system calls.
> > > 
> > > Ick, what?  Why not?
> > >
> > > > Pls add mmap support to the raw format.
> > > 
> > > For a single integer?  Why do you need mmap for this?  What is so
> > > "performant" that needs to touch a sysfs file?
> > > >    (Phys address is not guaranteed to be page-aligned so you will
> > > >     probably want an offset attribute for that as well).
> > > 
> > > Ick ick ick, that's why it's good to just stick with a sysfs file.
> > > 
> > > Have you tested just how long this takes to see if the open/read/close
> > > is really the bottleneck, or if the io on reading the value is the
> > > bottleneck?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Well an application needs to check this value basically after
> > every database transaction.
> 
> "every"?  That's horrid, why would you write a database that has to do
> an ACPI i/o call for every transaction?  That's a sure way to write a
> very slow database :(

Absolutely. That's why we might want to do an mmap and then get the ID
from memory. An alternative is poll support so userspace can get
notified about changes. Opens a bigger window during which you
are doing duplicate work, but maybe that's not such a big issue.

> > So I'm pretty sure it's a performance sensitive path.
> 
> Given that this api is not present today, why is this even needed?  Who
> wants/needs it so badly that it has to be tuned in ways like this?
> 
> If it is _really_ performant critical, just make it a new syscall :)

Maybe you are right and it is a premature optimization. Let's put it out
there without mmap support and see what happens - but then we definitely
need poll support.

> > But yes, I
> > didn't profile any apps since they
> > are yet to be written to use this interface.
> 
> Then what database are you talking about?  What apps need/want this
> thing?
> 
> thanks,
> 
> greg k-h

Anything that runs within a VM that is snapshoted is at risk
of sending duplicate transactions when it's restored and
time rolls back to a random point in the past.

If you want the application to have ability to detect these, then VM gen
ID offers a way to do it:
	id=read_id()
	do_work()
	new_id=read_id()
	if (new_id != id)
		find_and_handle_duplicate_work()


-- 
MST