Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Thomas Gleixner
On Sat, 7 Nov 2015, Dan Williams wrote: > Thanks for that explanation. Peter had alluded to it at KS, but I > indeed did not know that it was as horrible as milliseconds of > latency, hmm... Yes, I was pretty surprised as well. But even if it's just in the hundreds of microseconds it can be too

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Dan Williams
On Sat, Nov 7, 2015 at 12:38 AM, Thomas Gleixner wrote: > On Sat, 7 Nov 2015, Dan Williams wrote: >> On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: >> > On Fri, 6 Nov 2015, H. Peter Anvin wrote: >> >> On 11/06/15 15:17, Dan Williams wrote: >> >> >> >> >> >> Is it really required to do

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Thomas Gleixner
On Sat, 7 Nov 2015, Dan Williams wrote: > On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: > > On Fri, 6 Nov 2015, H. Peter Anvin wrote: > >> On 11/06/15 15:17, Dan Williams wrote: > >> >> > >> >> Is it really required to do that on all cpus? > >> > > >> > I believe it is, but I'll double

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Dan Williams
On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: > On Fri, 6 Nov 2015, H. Peter Anvin wrote: >> On 11/06/15 15:17, Dan Williams wrote: >> >> >> >> Is it really required to do that on all cpus? >> > >> > I believe it is, but I'll double check. >> > >> >> It's required on all CPUs on which

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Dan Williams
On Sat, Nov 7, 2015 at 12:38 AM, Thomas Gleixner wrote: > On Sat, 7 Nov 2015, Dan Williams wrote: >> On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: >> > On Fri, 6 Nov 2015, H. Peter Anvin wrote: >> >> On 11/06/15 15:17, Dan Williams wrote: >> >>

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Thomas Gleixner
On Sat, 7 Nov 2015, Dan Williams wrote: > On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: > > On Fri, 6 Nov 2015, H. Peter Anvin wrote: > >> On 11/06/15 15:17, Dan Williams wrote: > >> >> > >> >> Is it really required to do that on all cpus? > >> > > >> > I believe it

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Dan Williams
On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote: > On Fri, 6 Nov 2015, H. Peter Anvin wrote: >> On 11/06/15 15:17, Dan Williams wrote: >> >> >> >> Is it really required to do that on all cpus? >> > >> > I believe it is, but I'll double check. >> > >> >> It's required on

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-07 Thread Thomas Gleixner
On Sat, 7 Nov 2015, Dan Williams wrote: > Thanks for that explanation. Peter had alluded to it at KS, but I > indeed did not know that it was as horrible as milliseconds of > latency, hmm... Yes, I was pretty surprised as well. But even if it's just in the hundreds of microseconds it can be too

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Fri, 6 Nov 2015, H. Peter Anvin wrote: > On 11/06/15 15:17, Dan Williams wrote: > >> > >> Is it really required to do that on all cpus? > > > > I believe it is, but I'll double check. > > > > It's required on all CPUs on which the DAX memory may have been dirtied. > This is similar to the

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread H. Peter Anvin
On 11/06/15 15:17, Dan Williams wrote: >> >> Is it really required to do that on all cpus? > > I believe it is, but I'll double check. > It's required on all CPUs on which the DAX memory may have been dirtied. This is similar to the way we flush TLBs. -hpa -- To unsubscribe from

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Dan Williams
On Fri, Nov 6, 2015 at 9:35 AM, Thomas Gleixner wrote: > On Fri, 6 Nov 2015, Dan Williams wrote: >> On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: >> > Just for the record. Such a flush mechanism with >> > >> > on_each_cpu() >> > wbinvd() >> > ... >> > >> > will

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread H. Peter Anvin
On November 5, 2015 3:59:46 PM PST, Dan Williams wrote: >On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler > wrote: >> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >>> Ross Zwisler writes: >>> >>> > This series implements the very slow but correct handling for >>> >

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Fri, 6 Nov 2015, Dan Williams wrote: > On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: > > Just for the record. Such a flush mechanism with > > > > on_each_cpu() > > wbinvd() > > ... > > > > will make that stuff completely unusable on Real-Time systems. We've > >

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Dan Williams
On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: > On Thu, 5 Nov 2015, Dan Williams wrote: >> On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler >> wrote: >> > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >> >> Ross Zwisler writes: >> >> >> >> > This series implements the very

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Thu, 5 Nov 2015, Dan Williams wrote: > On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler > wrote: > > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: > >> Ross Zwisler writes: > >> > >> > This series implements the very slow but correct handling for > >> > blkdev_issue_flush() with

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread H. Peter Anvin
On 11/06/15 15:17, Dan Williams wrote: >> >> Is it really required to do that on all cpus? > > I believe it is, but I'll double check. > It's required on all CPUs on which the DAX memory may have been dirtied. This is similar to the way we flush TLBs. -hpa -- To unsubscribe from

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Dan Williams
On Fri, Nov 6, 2015 at 9:35 AM, Thomas Gleixner wrote: > On Fri, 6 Nov 2015, Dan Williams wrote: >> On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: >> > Just for the record. Such a flush mechanism with >> > >> > on_each_cpu() >> >

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Fri, 6 Nov 2015, H. Peter Anvin wrote: > On 11/06/15 15:17, Dan Williams wrote: > >> > >> Is it really required to do that on all cpus? > > > > I believe it is, but I'll double check. > > > > It's required on all CPUs on which the DAX memory may have been dirtied. > This is similar to the

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Thu, 5 Nov 2015, Dan Williams wrote: > On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler > wrote: > > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: > >> Ross Zwisler writes: > >> > >> > This series implements the very slow

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Dan Williams
On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: > On Thu, 5 Nov 2015, Dan Williams wrote: >> On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler >> wrote: >> > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >> >> Ross Zwisler

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread Thomas Gleixner
On Fri, 6 Nov 2015, Dan Williams wrote: > On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote: > > Just for the record. Such a flush mechanism with > > > > on_each_cpu() > > wbinvd() > > ... > > > > will make that stuff completely unusable on Real-Time

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-06 Thread H. Peter Anvin
On November 5, 2015 3:59:46 PM PST, Dan Williams wrote: >On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler > wrote: >> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >>> Ross Zwisler writes: >>> >>> >

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-05 Thread Dan Williams
On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler wrote: > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >> Ross Zwisler writes: >> >> > This series implements the very slow but correct handling for >> > blkdev_issue_flush() with DAX mappings, as discussed here: >> > >> >

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-11-05 Thread Dan Williams
On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler wrote: > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: >> Ross Zwisler writes: >> >> > This series implements the very slow but correct handling for >> > blkdev_issue_flush()

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Dan Williams
On Thu, Oct 29, 2015 at 7:24 AM, Jeff Moyer wrote: > Ross Zwisler writes: > >> This series implements the very slow but correct handling for >> blkdev_issue_flush() with DAX mappings, as discussed here: >> >> https://lkml.org/lkml/2015/10/26/116 >> >> I don't think that we can actually do the >>

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Ross Zwisler
On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: > Ross Zwisler writes: > > > This series implements the very slow but correct handling for > > blkdev_issue_flush() with DAX mappings, as discussed here: > > > > https://lkml.org/lkml/2015/10/26/116 > > > > I don't think that we can

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Jeff Moyer
Ross Zwisler writes: > This series implements the very slow but correct handling for > blkdev_issue_flush() with DAX mappings, as discussed here: > > https://lkml.org/lkml/2015/10/26/116 > > I don't think that we can actually do the > > on_each_cpu(sync_cache, ...); > > ...where sync_cache

[PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Ross Zwisler
This series implements the very slow but correct handling for blkdev_issue_flush() with DAX mappings, as discussed here: https://lkml.org/lkml/2015/10/26/116 I don't think that we can actually do the on_each_cpu(sync_cache, ...); ...where sync_cache is something like: cache_disable();

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Ross Zwisler
On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote: > Ross Zwisler writes: > > > This series implements the very slow but correct handling for > > blkdev_issue_flush() with DAX mappings, as discussed here: > > > > https://lkml.org/lkml/2015/10/26/116 > > > >

[PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Ross Zwisler
This series implements the very slow but correct handling for blkdev_issue_flush() with DAX mappings, as discussed here: https://lkml.org/lkml/2015/10/26/116 I don't think that we can actually do the on_each_cpu(sync_cache, ...); ...where sync_cache is something like: cache_disable();

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Jeff Moyer
Ross Zwisler writes: > This series implements the very slow but correct handling for > blkdev_issue_flush() with DAX mappings, as discussed here: > > https://lkml.org/lkml/2015/10/26/116 > > I don't think that we can actually do the > > on_each_cpu(sync_cache,

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

2015-10-28 Thread Dan Williams
On Thu, Oct 29, 2015 at 7:24 AM, Jeff Moyer wrote: > Ross Zwisler writes: > >> This series implements the very slow but correct handling for >> blkdev_issue_flush() with DAX mappings, as discussed here: >> >> https://lkml.org/lkml/2015/10/26/116