From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
Auger Eric <eric.auger@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Wei Yang <richardw.yang@linux.intel.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disable) by two discard types
Date: Tue, 20 Oct 2020 17:30:48 -0400 [thread overview]
Message-ID: <20201020213048.GG200400@xz-x1> (raw)
In-Reply-To: <20201020204929.GF200400@xz-x1>
On Tue, Oct 20, 2020 at 04:49:29PM -0400, Peter Xu wrote:
> On Tue, Oct 20, 2020 at 09:58:34PM +0200, David Hildenbrand wrote:
> > I remember there were some !BQL users (but I might be confusing it with
> > postcopy code that once used to inhibit the balloon without BQL). Will
> > double-check. Simplifying it is certainly a good idea.
> >
> > (we want to be able to check from virtio-balloon code repeatedly without
> > taking a mutex over and over again :) )
>
> Right. Again I've no strong opinion so feel free to keep the codes as wish.
> However if we'd go the other way (either BQL or another mutex) IMHO we can
> simply read that flag directly without taking mutex. IMHO here the mutex can
> be used to protect write concurrency and should be enough. Considering that
> this flag should rarely change and it should never flip (e.g., positive would
> never go negative, and vise versa), then READ_ONCE() whould be safe enough on
> read side (e.g., balloon).
Btw, what we've discussed is all about serialzation of the flag. I'm also
thinking about whether we can make the flag clearer on what it means. Frankly
speaking on the first glance it confused me quite a bit..
IMHO what we may want is not some complicated counter on "disablement", but
some simple counters on "someone that provided the cap to discard pages", and
"someone that won't work if we _might_ discard pages". I'm thinking what if we
split the "disable" counter into two:
- ram_discard_providers ("Who allows ram discard"): balloon, virtio-mem
- ram_discard_opposers ("Who forbids ram discard"): vfio, rdma, ...
The major benefit is, the counters should always be >=0, as what a usual
counter would do. Each device/caller should only/majorly increase the counter.
Also we don't need the cmpxchg() loops too since the check is easier - just
read the other side of the counters to know whether we should fail now.
So after this patch to introduce "coordinated discards", the counters can also
grows into four (we can still define some arrays):
|---------------------------+------------+-----------|
| counters | provider | opposer |
|---------------------------+------------+-----------|
| RAM_DISCARD_COORDINATED | virtio-mem | rdma, ... |
| RAM_DISCARD_UNCOORDINATED | balloon | vfio |
|---------------------------+------------+-----------|
Some examples: for vfio, it only needs to make sure no UNCOORDINATE providers.
For rdma, it needs to make sure no COORDINATE/UNCOORDINATE providers. The
check helper could simply be done using a similar ANY bitmask as introduced in
the current patch.
Not sure whether this may help.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2020-10-20 21:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 16:04 [PATCH PROTOTYPE 0/6] virtio-mem: vfio support David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 1/6] memory: Introduce sparse RAM handler for memory regions David Hildenbrand
2020-10-20 19:24 ` Peter Xu
2020-10-20 20:13 ` David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 2/6] virtio-mem: Impelement SparseRAMHandler interface David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 3/6] vfio: Implement support for sparse RAM memory regions David Hildenbrand
2020-10-20 19:44 ` Peter Xu
2020-10-20 20:01 ` David Hildenbrand
2020-10-20 20:44 ` Peter Xu
2020-11-12 10:11 ` David Hildenbrand
2020-11-18 13:04 ` David Hildenbrand
2020-11-18 15:23 ` Peter Xu
2020-11-18 16:14 ` David Hildenbrand
2020-11-18 17:01 ` Peter Xu
2020-11-18 17:37 ` David Hildenbrand
2020-11-18 19:05 ` Peter Xu
2020-11-18 19:20 ` David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disable) by two discard types David Hildenbrand
2020-10-20 19:17 ` Peter Xu
2020-10-20 19:58 ` David Hildenbrand
2020-10-20 20:49 ` Peter Xu
2020-10-20 21:30 ` Peter Xu [this message]
2020-09-24 16:04 ` [PATCH PROTOTYPE 5/6] virtio-mem: Require only RAM_BLOCK_DISCARD_T_COORDINATED discards David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 6/6] vfio: Disable only RAM_BLOCK_DISCARD_T_UNCOORDINATED discards David Hildenbrand
2020-09-24 19:30 ` [PATCH PROTOTYPE 0/6] virtio-mem: vfio support no-reply
2020-09-29 17:02 ` Dr. David Alan Gilbert
2020-09-29 17:05 ` David Hildenbrand
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=20201020213048.GG200400@xz-x1 \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta.linux@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richardw.yang@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).