Received: by 10.192.165.148 with SMTP id m20csp3799492imm; Mon, 7 May 2018 20:10:57 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqrsqMyxwoJTdcXuXOH5+05yB90qAbiOyJQr9K8QzjN/NksI46qOy2EbhpfD4N0DbM/DgpP X-Received: by 2002:a63:2ace:: with SMTP id q197-v6mr31801853pgq.60.1525749057004; Mon, 07 May 2018 20:10:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525749056; cv=none; d=google.com; s=arc-20160816; b=AP6j8v+t/HIbfwzEEKHnimJxGlzw23zjlPaLyp9dvHq06uPbVb8MmyScl8aU6s5GBj EASEAmrCVnM2ZByE/n/6YA7qriGCxopmNSMRC0fum2f5CqkdjKoz91A9KBjki28POAGG gAYlnlVCoESiRrBCybRhp6vZwixz0IIs6rfq9azxib/5652w1FY498a++uwWY4Kezkc2 uxfnRrP+1ErPE+w3AZTvXOcF3u68frxz2WlyipB+LwUOJtn3g9FTpr5NFBs4wr15G+IE XVD3u0o1gTR1tqkCEuBzHqaVHHMz0mABrWZU/h2n7L0DiW/FPqDRiDGAnGz4XCdZqmq4 LMNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=TzxswcoOQtv1Vh1Ub5pfzgh5KeQCtk4cmXbxkelMCV0=; b=SCE/2mf/qlrL9BtuPEL/UhdL/CZTp/24Tl/MkN59i3IX2ApaXi/7s/kshxCxOzIKhY wAyHA7FWZ8JswZ4amvoY1cvwBE61rlKaeu553IM5qJTH8q8Cb2uOyUozi+WY0VSUaytN cZUT4nlrnNAMZCq+90ouoVYH/HurryMO4kNoZH6PMOHjzIWcktSUpUVYSdNoWT1Ocfg4 sJcLJkxwUN1pd15DnPwxPCWmxewGS/hVEkctZ3WkYHuczy3ysa+pYEe083oYHFMNeAcH mfe4oSxY2VKmZ4hvz6X5h2ol9V2J+1p3NlCSu8uy4T0mNwqdJWFiBaD0JNuf93wNFnrF xISg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=G9nTdf6Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si8108194plx.236.2018.05.07.20.10.42; Mon, 07 May 2018 20:10:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=G9nTdf6Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754135AbeEHDKJ (ORCPT + 99 others); Mon, 7 May 2018 23:10:09 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:37208 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753785AbeEHDKI (ORCPT ); Mon, 7 May 2018 23:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TzxswcoOQtv1Vh1Ub5pfzgh5KeQCtk4cmXbxkelMCV0=; b=G9nTdf6Q/5GJAhSMC6+bPUOPO ywV7QIvHk2qV23J2ydbAchj9tSu1mBm0ifElIlBOyQSwltXsoI46qW5SwxNbqwsx+Ce5uegQf4j4y O+PApmTvHYvBcfJmDMfu37L0mQqwhmr0W0o/vd2CVMfHo1ly5QatnGMCDzD6HAa4a45GAoPcvHb72 ZBY+fVpA+6VohokI5KRlOmEu5F+RvSAFXXzxGs4/jq/OA4XRGBAuqQpt3zIDDcAMjtUUCN11pdABq t/tMWtuyoHJn3l+xz0Tj9f7Q6GqKxqo6uZ4n3YcVMR0Aba/8DB9Bvkhkd97H6FamA8eqf2AzE84UI 8LegHY96Q==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fFt0p-0004h2-MZ; Tue, 08 May 2018 03:09:59 +0000 Date: Mon, 7 May 2018 20:09:59 -0700 From: Matthew Wilcox To: Huaisheng HS1 Ye Cc: Jeff Moyer , Dan Williams , Michal Hocko , linux-nvdimm , Tetsuo Handa , NingTing Cheng , Dave Hansen , Linux Kernel Mailing List , "pasha.tatashin@oracle.com" , Linux MM , "colyli@suse.de" , Johannes Weiner , Andrew Morton , Sasha Levin , Mel Gorman , Vlastimil Babka Subject: Re: [External] Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Message-ID: <20180508030959.GB16338@bombadil.infradead.org> References: <1525704627-30114-1-git-send-email-yehs1@lenovo.com> <20180507184622.GB12361@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 08, 2018 at 02:59:40AM +0000, Huaisheng HS1 Ye wrote: > Currently in our mind, an ideal use scenario is that, we put all page caches to > zone_nvm, without any doubt, page cache is an efficient and common cache > implement, but it has a disadvantage that all dirty data within it would has risk > to be missed by power failure or system crash. If we put all page caches to NVDIMMs, > all dirty data will be safe. That's a common misconception. Some dirty data will still be in the CPU caches. Are you planning on building servers which have enough capacitance to allow the CPU to flush all dirty data from LLC to NV-DIMM? Then there's the problem of reconnecting the page cache (which is pointed to by ephemeral data structures like inodes and dentries) to the new inodes. And then you have to convince customers that what you're doing is safe enough for them to trust it ;-)