From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752232AbbKGJZG (ORCPT ); Sat, 7 Nov 2015 04:25:06 -0500 Received: from www.linutronix.de ([62.245.132.108]:34900 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbbKGJZB (ORCPT ); Sat, 7 Nov 2015 04:25:01 -0500 Date: Sat, 7 Nov 2015 10:24:06 +0100 (CET) From: Thomas Gleixner To: Dan Williams cc: "H. Peter Anvin" , Ross Zwisler , Jeff Moyer , linux-nvdimm , X86 ML , Dave Chinner , "linux-kernel@vger.kernel.org" , Ingo Molnar , Jan Kara Subject: Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness In-Reply-To: Message-ID: References: <1446070176-14568-1-git-send-email-ross.zwisler@linux.intel.com> <20151028225112.GA30284@linux.intel.com> <563D4B2F.9010608@zytor.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 much for latency sensitive applications. > One other mitigation that follows on with Dave's plan of per-inode DAX > control, is to also track when an inode has a writable DAX mmap > established. With that we could have a REQ_DAX flag to augment > REQ_FLUSH to potentially reduce committing violence on the cache. In > an earlier thread I also recall an idea to have an mmap flag that an > app can use to say "yes, I'm doing a writable DAX mapping, but I'm > taking care of the cache myself". We could track innocent cpus, but > I'm thinking that would be a core change to write-protect pages when a > thread migrates? In general I feel there's a limit for how much > hardware workaround is reasonable to do in the core kernel vs waiting > for the platform to offer better options... One thing vs. the mmaps: We exactly know which CPUs are involved in that mapping. We know that from the TLB management. So we probably can make use of that knowledge. > Sorry if I'm being a bit punchy, but I'm still feeling like I need to > defend the notion that DAX may just need to be turned off in some > situations. That's fine, if there is no reasonable way around it. It just needs to be documented so people won't be surprised. Thanks, tglx