Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1295632

Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

From Andrew Cooper <andrew.cooper3@citrix.com>
Newsgroups linux.kernel
Subject Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
Date 2015-12-20 18:10 +0100
Message-ID <qHPEC-3pl-29@gated-at.bofh.it> (permalink)
References (2 earlier) <qGGDo-8kx-13@gated-at.bofh.it> <qGHg5-60-1@gated-at.bofh.it> <qGHSN-EG-1@gated-at.bofh.it> <qGHSO-EG-15@gated-at.bofh.it> <qHItr-7bp-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 20/12/15 09:25, Michael S. Tsirkin wrote:
> On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
>> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
>>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
>>>> You could of course go fix that instead of mutilating things into
>>>> sort-of functional state.
>>> Yes, we'd just need to touch all architectures, all for
>>> the sake of UP which almost no one uses.
>>> Basically, we need APIs that explicitly are
>>> for talking to another kernel on a different CPU on
>>> the same SMP system, and implemented identically
>>> between CONFIG_SMP and !CONFIG_SMP on all architectures.
>>>
>>> Do you think this is something of general usefulness,
>>> outside virtio?
>> I'm not aware of any other case, but if there are more parts of virt
>> that need this then I see no problem adding it.
> When I wrote this, I assumed there are no other users, and I'm still not
> sure there are other users at the moment. Do you see a problem then?
>
>> That is, virt in general is the only use-case that I can think of,
>> because this really is an artifact of interfacing with an SMP host while
>> running an UP kernel.
> Or another guest kernel on an SMP host.
>
>> But I'm really not familiar with virt, so I do not know if there's more
>> sites outside of virtio that could use this.
>> Touching all archs is a tad tedious, but its fairly straight forward.
> So I looked and I was only able to find other another possible user in Xen.
>
> Cc Xen folks.
>
> I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> For example:
>
>                 /* Must write data /after/ reading the consumer index.  * */
>                 mb();
>
>                 memcpy(dst, data, avail);
>                 data += avail;
>                 len -= avail;
>         
>                 /* Other side must not see new producer until data is * there. */
>                 wmb();
>                 intf->req_prod += avail;
>                 
>                 /* Implies mb(): other side will see the updated producer. */
>                 notify_remote_via_evtchn(xen_store_evtchn);
>
> To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
>
> Is my analysis correct?

Correct.  The reason full barriers are used is so non-SMP guests still
function correctly.  It is certainly inefficient.

>
> So what I'm suggesting is something like the below patch,
> except instead of using virtio directly, a new set of barriers
> that behaves identically for SMP and non-SMP guests will be introduced.
>
> And of course the weak barriers flag is not needed for Xen -
> that's a virtio only thing.
>
> For example:
>
> smp_pv_wmb()
> smp_pv_rmb()
> smp_pv_mb()
>
> I'd like to get confirmation from Xen folks before posting
> this patchset.
>
> Comments/suggestions?

Very much +1 for fixing this.

Those names would be fine, but they do add yet another set of options in
an already-complicated area.

An alternative might be to have the regular smp_{w,r,}mb() not revert
back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a
non-native environment.  (I don't know how feasible this suggestion is,
however.)

~Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 11:40 +0100
  Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 12:00 +0100
    Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 14:20 +0100
      Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 15:00 +0100
        Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 15:40 +0100
          Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 15:40 +0100
            Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 15:50 +0100
            new barrier type for paravirt (was Re: [PATCH] virtio_ring: use  smp_store_mb) "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-20 10:30 +0100
              Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH]  virtio_ring: use smp_store_mb) Andrew Cooper <andrew.cooper3@citrix.com> - 2015-12-20 18:10 +0100
                Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH]  virtio_ring: use smp_store_mb) Peter Zijlstra <peterz@infradead.org> - 2015-12-20 21:10 +0100
                Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH]  virtio_ring: use smp_store_mb) "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-21 08:20 +0100
                [PATCH RFC] smp_store_mb should use smp_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-21 08:30 +0100
              Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring:  use smp_store_mb) David Vrabel <david.vrabel@citrix.com> - 2015-12-21 11:50 +0100
                Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH]  virtio_ring: use smp_store_mb) "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-21 13:00 +0100
                Re: [Qemu-devel] [Xen-devel] new barrier type for paravirt (was Re:  [PATCH] virtio_ring: use smp_store_mb) Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-21 16:00 +0100
  Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 12:30 +0100
    Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 14:30 +0100
      Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 15:10 +0100
        Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 15:40 +0100
          Re: [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2015-12-17 16:10 +0100
            Re: [PATCH] virtio_ring: use smp_store_mb Will Deacon <will.deacon@arm.com> - 2015-12-17 17:00 +0100
              Re: [PATCH] virtio_ring: use smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-17 20:30 +0100

csiph-web