lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 7 Nov 2015 07:50:16 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: "H. Peter Anvin" <hpa@...or.com> cc: Dan Williams <dan.j.williams@...el.com>, Ross Zwisler <ross.zwisler@...ux.intel.com>, Jeff Moyer <jmoyer@...hat.com>, linux-nvdimm <linux-nvdimm@...1.01.org>, X86 ML <x86@...nel.org>, Dave Chinner <david@...morbit.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.com> Subject: Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness 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. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists