search for: coherencies

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 7e38ed79c3fc..961af25b385c 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -20,6 +20,7 @@ > >

On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 7e38ed79c3fc..961af25b385c 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -20,6 +20,7 @@ > >

On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > By forcing on DMA API usage for ARM systems, we have inadvertently > kicked open a hornets' nest in terms of cache-coherency. Namely that > unless the virtio device is explicitly described as capable of coherent > DMA by firmware, the DMA APIs on ARM and other DT-based platforms will > assume it is non-coherent.

On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote: > On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > > On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > index 7e38ed79c3fc..961af25b385c 100644 > > > --- a/drivers/virtio/virtio_ring.c

...e I got is always 1. On a website, it says: " Note that if the ensemble averaging were to be omitted, the coherency (squared) would be 1, independent of the data". Does any of you know how to specify properly in R in order to get more useful coherency? The examples in the help do give coherencies that are not 1s, but I did not notice any special specification. Next question is on co-spectrum. When I supply "spectrum" function with multiple time series, it only gives me spectrum (smoothed periodogram) of individual time series. Is there any way I can get the cross-spectrum? I...

On 02/01/2017 08:19 PM, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote: >> On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: >>> On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: >>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >>>> index

On 02/01/2017 08:19 PM, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote: >> On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: >>> On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: >>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >>>> index

On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > By forcing on DMA API usage for ARM systems, we have inadvertently > kicked open a hornets' nest in terms of cache-coherency. Namely that > unless the virtio device is explicitly described as capable of coherent > DMA by firmware, the DMA APIs on ARM and other DT-based platforms will > assume it is non-coherent.

On Thu, Dec 17, 2015 at 04:09:17PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 04:34:57PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > > > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > > Author: Alexander Duyck <alexander.h.duyck at redhat.com> > > > > Date:

On Thu, Dec 17, 2015 at 04:09:17PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 04:34:57PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > > > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > > Author: Alexander Duyck <alexander.h.duyck at redhat.com> > > > > Date:

Currently, default behavior of O_DIRECT writes was allowing concurrent writing among nodes, no cluster coherency guaranteed (no EX locks was taken), it hurts buffered reads on other nodes by reading stale data from cache. The new mount option introduce a chance to choose two different behaviors for O_DIRECT writes: * coherency=full, as the default value, will disallow concurrent

On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:26:29PM +0200, Michael S. Tsirkin wrote: > > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > > > that they use dma_* ops for weak_barriers, while virtio_mb() uses > > > smp_mb(). > > > > It's a hack really. I think I'll clean it

On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:26:29PM +0200, Michael S. Tsirkin wrote: > > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > > > that they use dma_* ops for weak_barriers, while virtio_mb() uses > > > smp_mb(). > > > > It's a hack really. I think I'll clean it

Greetings, I would like to estimate a spectral coherence between two timeseries. The stats : spectrum() returns a coh matrix which estimates coherence (squared). A basic test which from which i expect near-zero coherence: x = rnorm(500) y = rnorm(500) xts = ts(x, frequency = 10) yts = ts(y, frequency = 10) gxy = spectrum( cbind( xts, yts ) ) plot( gxy $ freq, gxy $

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On Thu, Feb 09, 2017 at 08:17:16PM +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > > > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > > > I am inclined to say, for 4.10 let's revert > > > >

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On Thu, Feb 09, 2017 at 08:17:16PM +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > > > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > > > I am inclined to say, for 4.10 let's revert > > > >

On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > I am inclined to say, for 4.10 let's revert > > c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a > > regression in 4.10. > > No complaints there, as long as we can keep working to fix this for 4.11 > and

On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > I am inclined to say, for 4.10 let's revert > > c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a > > regression in 4.10. > > No complaints there, as long as we can keep working to fix this for 4.11 > and