From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755090AbbIBQTK (ORCPT ); Wed, 2 Sep 2015 12:19:10 -0400 Received: from mga11.intel.com ([192.55.52.93]:3594 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751268AbbIBQTI (ORCPT ); Wed, 2 Sep 2015 12:19:08 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,454,1437462000"; d="scan'208";a="637195249" Subject: Re: [PATCH] dax, pmem: add support for msync To: Boaz Harrosh , Dave Chinner , Ross Zwisler , Christoph Hellwig , linux-kernel@vger.kernel.org, Alexander Viro , Andrew Morton , "H. Peter Anvin" , Hugh Dickins , Ingo Molnar , "Kirill A. Shutemov" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, Matthew Wilcox , Peter Zijlstra , Thomas Gleixner , x86@kernel.org References: <1441047584-14664-1-git-send-email-ross.zwisler@linux.intel.com> <20150831233803.GO3902@dastard> <20150901070608.GA5482@lst.de> <20150901222120.GQ3902@dastard> <20150902031945.GA8916@linux.intel.com> <20150902051711.GS3902@dastard> <55E6CF15.4070105@plexistor.com> <55E70653.4090302@linux.intel.com> <55E7132E.104@plexistor.com> <55E7184B.3020104@linux.intel.com> <55E71D00.4050103@plexistor.com> From: Dave Hansen Message-ID: <55E7217B.2090803@linux.intel.com> Date: Wed, 2 Sep 2015 09:19:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E71D00.4050103@plexistor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/2015 09:00 AM, Boaz Harrosh wrote: >> > We are going to have 2-socket systems with 6TB of persistent memory in >> > them. I think it's important to design this mechanism so that it scales >> > to memory sizes like that and supports large mmap()s. >> > >> > I'm not sure the application you've seen thus far are very >> > representative of what we want to design for. >> > > We have a patch pending to introduce a new mmap flag that pmem aware > applications can set to eliminate any kind of flushing. MMAP_PMEM_AWARE. Great! Do you have a link so that I can review it and compare it to Ross's approach?