[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Adopting the Linux Kernel Memory Model in Xen?



> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Julien 
> Grall
> Sent: 11 September 2020 17:34
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx; committers@xxxxxxxxxxxxxx
> Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>; Bertrand Marquis 
> <Bertrand.Marquis@xxxxxxx>
> Subject: Adopting the Linux Kernel Memory Model in Xen?
> 
> Hi all,
> 
> At the moment, Xen doesn't have a formal memory model. Instead, we are
> relying on intuitions. This can lead to heated discussion on what can a
> processor/compiler do or not.
> 

...which, in turn, may well lead us into decisions that harm performance.

> We also have some helpers that nearly do the same (such as
> {read,write}_atomic() vs ACCESS_ONCE()) with no clear understanding
> where to use which.
> 
> In the past few years, Linux community spent a lot of time to write down
> their memory model and make the compiler communities aware of it (see
> [1], [2]).
> 
> There are a few reasons I can see for adopting LKMM:
>     - Xen borrows a fair amount of code from Linux;

...and essentially the same toolchain(s)

>     - There are efforts to standardize it;
>     - This will allow us to streamline the discussion.
> 
> Any thoughts?
> 

It seems like a very good idea to me.

  Paul

> Cheers,
> 
> [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html
> 
> 
> --
> Julien Grall





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.