Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Mikulas Patocka]

On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:

> On Wed, 22 Aug 2018, Sinan Kaya wrote:
> 
> > > It's hard to tell. The Alpha manual says that only overlapping accesses
> > > are ordered.
> > > 
> > > I did some tests on framebuffer and found out that "read+read+write+write"
> > > is faster than "read+write+read+write" - that may suggest that the reads
> > > flush the write queue.
> > 
> > Do you know if the framebuffer BAR you are using is non-prefetchable? (you
> > can find out from lspci)
> > 
> > Ordering rule only applies to non-prefetchable BARs only. Architectures are
> > allowed to do whatever they want for for prefetchable BARs.
> 
>  Well, data accesses have to reach the relevant PCI host bridge first 
> (i.e. leave the CPU and pass through any intermediate bus bridges between 
> the CPU and the PCI bus tree accessed) for any PCI data ordering rules to 
> apply.  Depending on the system architecture this may or may not require 
> OS software intervention.  NB this is a general observation, not specific 
> to Alpha.
> 
>  "Alpha Architecture Handbook" has an extensive discussion on data 
> ordering, concerning both memory and MMIO (termed "memory-like region" and 
> "non-memory-like region" respectively in the said document), and I'll try 
> to get through all of it in the coming days to see if I can get to a 
> conclusion which will let us avoid excessive synchronisation.
> 
>  Meanwhile I'll be happy of course to accept any input backed with 
> suitable references.
> 
>   Maciej

According to the Alpha handbook, non-overlapping accesses may be 
reordered.

So if someone does 
writel(REG1);
readl(REG2);

readl may (according to the spec) reach the device before writel. Although 
actual experiments suggests that the read flushes the queued writes.

I would be quite interested why did Linux developers decide that readl 
should be implemented as "read+barrier" and writel should be implemented 
as "barrier+write". Why is there this assymetry in the barriers?

Does ARM have some hardware magic that prevents reordering the write and 
the read in this case?

Will Deacon made the change to "memory-barriers.txt" to specify this 
requirement - could you please describe why did you specify it this way?

Mikulas

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Arnd Bergmann]

On Wed, Aug 22, 2018 at 5:50 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:
> > On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
> According to the Alpha handbook, non-overlapping accesses may be
> reordered.
>
> So if someone does
> writel(REG1);
> readl(REG2);
>
> readl may (according to the spec) reach the device before writel. Although
> actual experiments suggests that the read flushes the queued writes.
>
> I would be quite interested why did Linux developers decide that readl
> should be implemented as "read+barrier" and writel should be implemented
> as "barrier+write". Why is there this assymetry in the barriers?

I can explain this part: those two barriers are used specifically do order
an MMIO access against a DMA access: a writel() may be used to start
a DMA operation copying data from RAM to the device, so we must
have a barrier between the store to that data and the store to the register
to ensure the data is visible to the device.
Similarly, a readl() may check the status of a register that tells us when
a DMA from device to RAM has completed. We must have a read
barrier between that mmio load and the load from RAM to prevent
the data to be prefetched while the MMIO is still in progress.

> Does ARM have some hardware magic that prevents reordering the write and
> the read in this case?

Most architecture have this AFAICT, ARM and x86 definitely do, and
PCI requires this to be true on the bus:

All MMIO accesses from a given CPU to a given device (according
to an architecture-specific definition of "device") are ordered with respect
to one another.

If the hardware does not guarantee that, for simple load/store operations
on uncached device memory, then we need a full barrier after each store
in addition to the write barrier needed for the DMA synchronization.

      Arnd

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Maciej W. Rozycki]

On Wed, 22 Aug 2018, Arnd Bergmann wrote:

> > According to the Alpha handbook, non-overlapping accesses may be
> > reordered.

 I have had a notion of this since forever, however I have had troubles 
tracking down the exact reference in the architecture specification.

> > So if someone does
> > writel(REG1);
> > readl(REG2);
> >
> > readl may (according to the spec) reach the device before writel. Although
> > actual experiments suggests that the read flushes the queued writes.

 Individual implementations can surely be more strongly ordered than the 
architecture specification requires.

> > Does ARM have some hardware magic that prevents reordering the write and
> > the read in this case?
> 
> Most architecture have this AFAICT, ARM and x86 definitely do, and
> PCI requires this to be true on the bus:
> 
> All MMIO accesses from a given CPU to a given device (according
> to an architecture-specific definition of "device") are ordered with respect
> to one another.
> 
> If the hardware does not guarantee that, for simple load/store operations
> on uncached device memory, then we need a full barrier after each store
> in addition to the write barrier needed for the DMA synchronization.

 MIPS is architecturally even more weakly ordered and a set of barrier 
instructions has been defined for synchronisation: SYNC for a completion 
barrier, and SYNC_ACQUIRE, SYNC_RELEASE, SYNC_RMB, SYNC_WMB and SYNC_MB 
for various ordering barriers.  Older architecture revisions had this less 
standardised.  Many if not most implementations are more strongly ordered 
though, in which case the relevant SYNC instructions are effectively NOPs.

 I'd expect some other architectures to be similarly weakly ordered.

 FWIW,

  Maciej

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Mikulas Patocka]

On Wed, 22 Aug 2018, Arnd Bergmann wrote:

> On Wed, Aug 22, 2018 at 5:50 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> > On Wed, 22 Aug 2018, Maciej W. Rozycki wrote:
> > > On Wed, 22 Aug 2018, Sinan Kaya wrote:
> >
> > According to the Alpha handbook, non-overlapping accesses may be
> > reordered.
> >
> > So if someone does
> > writel(REG1);
> > readl(REG2);
> >
> > readl may (according to the spec) reach the device before writel. Although
> > actual experiments suggests that the read flushes the queued writes.
> >
> > I would be quite interested why did Linux developers decide that readl
> > should be implemented as "read+barrier" and writel should be implemented
> > as "barrier+write". Why is there this assymetry in the barriers?
> 
> I can explain this part: those two barriers are used specifically do order
> an MMIO access against a DMA access: a writel() may be used to start
> a DMA operation copying data from RAM to the device, so we must
> have a barrier between the store to that data and the store to the register
> to ensure the data is visible to the device.
> Similarly, a readl() may check the status of a register that tells us when
> a DMA from device to RAM has completed. We must have a read
> barrier between that mmio load and the load from RAM to prevent
> the data to be prefetched while the MMIO is still in progress.

Then - the question is - why not just use barriers before and after 
accesses to DMA'd memory? For DMA into non-coheren memory, the barrier 
could be injected into dma_map_* and dma_unmap_* functions (with no change 
in drivers) - and for DMA into coherent memory you could have something 
like dma_coherent_barrier().

Why does Linux add the barriers between every read and write to memory 
mapped registers?

> > Does ARM have some hardware magic that prevents reordering the write and
> > the read in this case?
> 
> Most architecture have this AFAICT, ARM and x86 definitely do, and
> PCI requires this to be true on the bus:
> 
> All MMIO accesses from a given CPU to a given device (according
> to an architecture-specific definition of "device") are ordered with respect
> to one another.

If ARM guarantees that the accesses to a given device are not reordered - 
then the barriers in readl and writel are superfluous.

> If the hardware does not guarantee that, for simple load/store operations
> on uncached device memory, then we need a full barrier after each store
> in addition to the write barrier needed for the DMA synchronization.
> 
>       Arnd

Mikulas

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Sinan Kaya]

On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> If ARM guarantees that the accesses to a given device are not reordered -
> then the barriers in readl and writel are superfluous.

It is not. ARM only guarantees ordering of read/write transactions targeting
a device not memory.

example:

write memory
raw write to device

or

raw read from device
read memory

these can bypass each other on ARM unless a barrier is placed in the right
place either via readl()/writel() or explicitly.


raw write to device
raw write to device

or

raw write to device
raw read from device

or

raw read from device
raw read from device

are guaranteed to be ordered on ARM without needing any explicit barrier.

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Mikulas Patocka]

On Wed, 22 Aug 2018, Sinan Kaya wrote:

> On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> > If ARM guarantees that the accesses to a given device are not reordered -
> > then the barriers in readl and writel are superfluous.
> 
> It is not. ARM only guarantees ordering of read/write transactions targeting
> a device not memory.
> 
> example:
> 
> write memory
> raw write to device
> 
> or
> 
> raw read from device
> read memory
> 
> these can bypass each other on ARM unless a barrier is placed in the right
> place either via readl()/writel() or explicitly.

Yes - but - why does Linux insert the barriers into readl() and writel() 
instead of inserting them between accesses to registers and memory?

A lot of drivers have long sequences of accesses to memory-mapped 
registers with no interleaving accesses to coherent memory and these 
implicit barriers slow them down with no gain at all.

Mikulas

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Will Deacon]

On Wed, Aug 22, 2018 at 03:56:28PM -0400, Mikulas Patocka wrote:
> 
> 
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
> 
> > On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> > > If ARM guarantees that the accesses to a given device are not reordered -
> > > then the barriers in readl and writel are superfluous.
> > 
> > It is not. ARM only guarantees ordering of read/write transactions targeting
> > a device not memory.
> > 
> > example:
> > 
> > write memory
> > raw write to device
> > 
> > or
> > 
> > raw read from device
> > read memory
> > 
> > these can bypass each other on ARM unless a barrier is placed in the right
> > place either via readl()/writel() or explicitly.
> 
> Yes - but - why does Linux insert the barriers into readl() and writel() 
> instead of inserting them between accesses to registers and memory?
> 
> A lot of drivers have long sequences of accesses to memory-mapped 
> registers with no interleaving accesses to coherent memory and these 
> implicit barriers slow them down with no gain at all.

That's what readX_relaxed and writeX_relaxed are for. There was some
discussion on the lists a way back, and Torvalds was very clear that readX
and writeX should follow the x86 semantics, which have these ordering
guarantees against accesses to memory.

Will

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Sinan Kaya]

On 8/22/2018 3:56 PM, Mikulas Patocka wrote:
> 
> 
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
> 
>> On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
>>> If ARM guarantees that the accesses to a given device are not reordered -
>>> then the barriers in readl and writel are superfluous.
>>
>> It is not. ARM only guarantees ordering of read/write transactions targeting
>> a device not memory.
>>
>> example:
>>
>> write memory
>> raw write to device
>>
>> or
>>
>> raw read from device
>> read memory
>>
>> these can bypass each other on ARM unless a barrier is placed in the right
>> place either via readl()/writel() or explicitly.
> 
> Yes - but - why does Linux insert the barriers into readl() and writel()
> instead of inserting them between accesses to registers and memory?
> 
> A lot of drivers have long sequences of accesses to memory-mapped
> registers with no interleaving accesses to coherent memory and these
> implicit barriers slow them down with no gain at all.

It is an abstraction issue. Majority of drivers are developed against x86
and the developers have no idea about the weakly ordered architecture
implications.

Now, Will Deacon added new primitives to address your concern. There are
new APIs as readl_relaxed() and writel_relaxed() as opposed to readl()
and writel().

Relaxed version still guarantee of register accesses with respect to each
other but no guaranteed with respect to memory. Relaxed versions could
be used in performance critical path.

> 
> Mikulas
> 

Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130

[Will Deacon]

[sorry, thought I replied on this thread already but my wifi is flakey]

On Wed, Aug 22, 2018 at 04:06:09PM -0400, Sinan Kaya wrote:
> On 8/22/2018 3:56 PM, Mikulas Patocka wrote:
> >
> >
> >On Wed, 22 Aug 2018, Sinan Kaya wrote:
> >
> >>On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> >>>If ARM guarantees that the accesses to a given device are not reordered -
> >>>then the barriers in readl and writel are superfluous.
> >>
> >>It is not. ARM only guarantees ordering of read/write transactions targeting
> >>a device not memory.
> >>
> >>example:
> >>
> >>write memory
> >>raw write to device
> >>
> >>or
> >>
> >>raw read from device
> >>read memory
> >>
> >>these can bypass each other on ARM unless a barrier is placed in the right
> >>place either via readl()/writel() or explicitly.
> >
> >Yes - but - why does Linux insert the barriers into readl() and writel()
> >instead of inserting them between accesses to registers and memory?
> >
> >A lot of drivers have long sequences of accesses to memory-mapped
> >registers with no interleaving accesses to coherent memory and these
> >implicit barriers slow them down with no gain at all.
> 
> It is an abstraction issue. Majority of drivers are developed against x86
> and the developers have no idea about the weakly ordered architecture
> implications.

Right, and Torvalds was very clear that readX/writeX must follow the x86
semantics here.

> Now, Will Deacon added new primitives to address your concern. There are
> new APIs as readl_relaxed() and writel_relaxed() as opposed to readl()
> and writel().
> 
> Relaxed version still guarantee of register accesses with respect to each
> other but no guaranteed with respect to memory. Relaxed versions could
> be used in performance critical path.

Yes, and the heavy ordering requirements of plain readX/writeX were exactly
what motivated the addition of the _relaxed forms.

Will