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

From	Dan Williams <dan.j.williams@intel.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness
Date	2015-11-07 09:20 +0100
Message-ID	<qs6T7-8cb-1@gated-at.bofh.it> (permalink)
References	(5 earlier) <qrRKr-6IF-29@gated-at.bofh.it> <qrT9x-7vW-11@gated-at.bofh.it> <qrYsx-2Hd-5@gated-at.bofh.it> <qs01j-3vl-3@gated-at.bofh.it> <qs5DI-7fZ-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner <tglx@linutronix.de> 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 the DAX memory may have been dirtied.
>>  This is similar to the way we flush TLBs.
>
> Right. And that's exactly the problem: "may have been dirtied"
>
> If DAX is used on 50% of the CPUs and the other 50% are plumming away
> happily in user space or run low latency RT tasks w/o ever touching
> it, then having an unconditional flush on ALL CPUs is just wrong
> because you penalize the uninvolved cores with a completely pointless
> SMP function call and drain their caches.
>

It's not wrong and pointless, it's all we have available outside of
having the kernel remember every virtual address that might have been
touched since the last fsync and sit in a loop flushing those virtual
address cache line by cache line.

There is a crossover point where wbinvd is better than a clwb loop
that needs to be determined.
--
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/

Thread

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-06 01:00 +0100
  Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-06 09:10 +0100
    Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-06 17:10 +0100
      Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-06 18:40 +0100
        Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 00:20 +0100
          Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness "H. Peter Anvin" <hpa@zytor.com> - 2015-11-07 02:00 +0100
            Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 08:00 +0100
              Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 09:20 +0100
                Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 09:50 +0100
                Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 10:10 +0100
                Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 10:30 +0100
  Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness "H. Peter Anvin" <hpa@zytor.com> - 2015-11-06 21:30 +0100

csiph-web