From: "Michael S. Tsirkin" <mst@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Or Idgar <idgar@virtualoco.com>,
linux-kernel@vger.kernel.org, arnd@arndb.de, oidgar@redhat.com,
ghammer@redhat.com, Or Idgar <oridgar@gmail.com>
Subject: Re: [PATCH v5] drivers/misc: vm_gen_counter: initial driver implementation
Date: Wed, 14 Mar 2018 21:25:17 +0200 [thread overview]
Message-ID: <20180314211704-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180314182536.GA14504@kroah.com>
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 :)
In particular, it changes whenever VM is migrated or snapshotted.
> > 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. So I'm pretty sure it's a performance
sensitive path. But yes, I didn't profile any apps since they
are yet to be written to use this interface.
I'm fine deferring point 2 for now.
--
MST
next prev parent reply other threads:[~2018-03-14 19:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 14:22 [PATCH v5] drivers/misc: vm_gen_counter: initial driver implementation Or Idgar
2018-03-13 17:40 ` Michael S. Tsirkin
2018-03-14 18:25 ` Greg KH
2018-03-14 19:25 ` Michael S. Tsirkin [this message]
2018-03-15 6:57 ` Gal Hammer
2018-03-15 12:55 ` Michael S. Tsirkin
2018-03-15 13:19 ` Greg KH
2018-03-15 13:46 ` Michael S. Tsirkin
2018-03-15 8:00 ` Gal Hammer
2018-03-15 13:31 ` Michael S. Tsirkin
2018-09-21 13:56 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180314211704-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=arnd@arndb.de \
--cc=ghammer@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=idgar@virtualoco.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oidgar@redhat.com \
--cc=oridgar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.