From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754050AbdEEWor (ORCPT ); Fri, 5 May 2017 18:44:47 -0400 Received: from g2t2353.austin.hpe.com ([15.233.44.26]:28853 "EHLO g2t2353.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751721AbdEEWoo (ORCPT ); Fri, 5 May 2017 18:44:44 -0400 X-Greylist: delayed 7499 seconds by postgrey-1.27 at vger.kernel.org; Fri, 05 May 2017 18:44:44 EDT From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "jmoyer@redhat.com" , "tglx@linutronix.de" , "hch@lst.de" , "viro@zeniv.linux.org.uk" , "x86@kernel.org" , "mawilcox@microsoft.com" , "hpa@zytor.com" , "linux-nvdimm@lists.01.org" , "mingo@redhat.com" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "jack@suse.cz" Subject: Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations Thread-Topic: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations Thread-Index: AQHSwFf2pYpBQohMYEm6dbBc4FPj86HmPreAgAAdeoCAAAVzgA== Date: Fri, 5 May 2017 22:44:40 +0000 Message-ID: <1494024273.30303.71.camel@hpe.com> References: <20170427063054.soejyqocqqrihfdw@gmail.com> <149340820800.28724.16189291963486607562.stgit@dwillia2-desk3.amr.corp.intel.com> <1494016773.30303.69.camel@hpe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.219.163.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AT5PR84MB0260;7:km7ZgC4IAIvZIIruKgcgQMdh7S3GVeJbb4RCojSxuk8I4ywgbAjLNgE7J2IMa1kbX7dNJCojUIa+zGGJhP2Z0JUn4j/IvSJrxTK6UGQGZCWfrz54fqhaGkIbqzr0QjJ8kXRMFh5i3dulvxtgD7qRJdPbIdypsSLDGjSqcphIy9dy8ztxgeotWDhHgUSb6mYBIBbenj09LEALOswDm5KFihmA6q/ridC5kaCjkIq/bw7rC9wWj7R9zUjDuKFUM37skPi8xLPZvhMg2e7CX69oLuOzunAAl7/pPs5MR0PWegL5WiR3p/XkomecIHq9PN/XTOecHZ78HsTi9d6jWo8twg== x-ms-office365-filtering-correlation-id: 488bd2cf-acbd-429f-cbc8-08d4940850df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:AT5PR84MB0260; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201703061421075)(201703161042150)(6042181)(6072148);SRVR:AT5PR84MB0260;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0260; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(377454003)(377424004)(24454002)(6246003)(6506006)(6436002)(33646002)(5640700003)(7416002)(8666007)(110136004)(4326008)(54906002)(3660700001)(76176999)(50986999)(8936002)(6486002)(53936002)(2906002)(86362001)(38730400002)(2351001)(2501003)(5660300001)(3846002)(6512007)(3280700002)(498600001)(7736002)(305945005)(102836003)(6116002)(54356999)(6916009)(189998001)(2950100002)(5250100002)(66066001)(53546009)(2900100001)(36756003)(229853002)(81166006)(103116003)(93886004)(25786009)(8676002);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0260;H:AT5PR84MB0260.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8A23498DC05EBE4FACADA88123ACAA65@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 22:44:40.2915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0260 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v45MiuYs013329 On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: > On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu > wrote: : > > > --- > > > Changes since the initial RFC: > > > * s/writethru/wt/ since we already have ioremap_wt(), > > > set_memory_wt(), etc. (Ingo) > > > > Sorry I should have said earlier, but I think the term "wt" is > > misleading.  Non-temporal stores used in memcpy_wt() provide WC > > semantics, not WT semantics. > > The non-temporal stores do, but memcpy_wt() is using a combination of > non-temporal stores and explicit cache flushing. > > > How about using "nocache" as it's been > > used in __copy_user_nocache()? > > The difference in my mind is that the "_nocache" suffix indicates > opportunistic / optional cache pollution avoidance whereas "_wt" > strictly arranges for caches not to contain dirty data upon > completion of the routine. For example, non-temporal stores on older > x86 cpus could potentially leave dirty data in the cache, so > memcpy_wt on those cpus would need to use explicit cache flushing. I see. I agree that its behavior is different from the existing one with "_nocache". That said, I think "wt" or "write-through" generally means that writes allocate cachelines and keep them clean by writing to memory. So, subsequent reads to the destination will hit the cachelines. This is not the case with this interface. Thanks, -Toshi