From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F373C17447 for ; Wed, 13 Nov 2019 06:14:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 018A821A49 for ; Wed, 13 Nov 2019 06:14:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="hJ6RPPBE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 018A821A49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6FD1E6B0005; Wed, 13 Nov 2019 01:14:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ADD96B000C; Wed, 13 Nov 2019 01:14:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 574D36B000D; Wed, 13 Nov 2019 01:14:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 3E36E6B0005 for ; Wed, 13 Nov 2019 01:14:19 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 87E08181AEF1D for ; Wed, 13 Nov 2019 06:14:18 +0000 (UTC) X-FDA: 76150239396.18.sink36_5fb1258a34a0b X-HE-Tag: sink36_5fb1258a34a0b X-Filterd-Recvd-Size: 5148 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Nov 2019 06:14:17 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id w24so166015otk.6 for ; Tue, 12 Nov 2019 22:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u8/eBOEFYWm/dQgNr/pNtbBC73p9IYMi5gGkpqo2SI4=; b=hJ6RPPBE1NoZf0/QVupYvy9OSDziN9tXHIJgPesa3XQzwUekMxqHmy4ywWzJ7olyYn S25aiGORN3SKrmbL/zg3J82nKwwPyIlH7PmQWbCLsU8YVru2546iAwoNbriXDphYCHP3 MpbJ6zeFfdnFYRNFEWoBo/jpLeE7M5vPyoMOZssjrCd54wlf2SAg74J9p7QSN2Rc3HbZ dxBhLBVLxCENTG/wdo2QS9QsWhp6iAHjPsEyxbnLxnN4Zf7etAvI1IsZWkGfHlLFA659 krN85FOxSocMTjuEy7YL4rUwZsNs9tYal7YQEvS3BOcZKt5J7hBKVU3FLEUJVZFKERpY 75eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u8/eBOEFYWm/dQgNr/pNtbBC73p9IYMi5gGkpqo2SI4=; b=cO3kmjbK/67Ya34PUibikQ5llyLstznegNeDgIcUpiHZSklSmbCtivm5+q0x9SfVvt 7lW/getq+An7TZEyeWHermTWtYPQMzf9lKXtx8F+YNWlg1DRvEEPxA9lG+gXMGDirKLJ RAaJWugKD+hWq5+fiJNankc4xV1FMkb4Yo2iMDElR3yfndxgjeQxOZtSPQ+tUX0bHp0W R3w1sJoMU5skpTNjpjafu7CQLe4sYBb3+bHVOsA/spyNVHJsDK3W/5PC28u/MqjyAhdo M5L0uhF3ESGFOwsfAGwrdrXC0pOIHDqg3FhZP+e3v7aA9LE87WLqnizC4KdZnqfpuKcv v+GA== X-Gm-Message-State: APjAAAUsZ/RjAFzO4KHcK016HW+Cc81TnJ3BEfz8ulq5JdAH/s1PMXld yiTUusp3DC71Wo+SzmxaORM689px0t0e1LWkyvIKsw== X-Google-Smtp-Source: APXvYqydyDDmkM3Pb1e2pPbf9fbI2BGEVuN/kDhx0lcoQbUla4YO7+zpV4A7M6u65IKIch5dF7aZebIgX7kFjMgndhw= X-Received: by 2002:a05:6830:1b70:: with SMTP id d16mr1213448ote.71.1573625656497; Tue, 12 Nov 2019 22:14:16 -0800 (PST) MIME-Version: 1.0 References: <157309899529.1582359.15358067933360719580.stgit@dwillia2-desk3.amr.corp.intel.com> <157309901655.1582359.18126990555058555754.stgit@dwillia2-desk3.amr.corp.intel.com> <87h839tpo9.fsf@linux.ibm.com> <738e328b-9a9b-b297-8379-f0d72d06c5c9@linux.ibm.com> In-Reply-To: <738e328b-9a9b-b297-8379-f0d72d06c5c9@linux.ibm.com> From: Dan Williams Date: Tue, 12 Nov 2019 22:14:04 -0800 Message-ID: Subject: Re: [PATCH 04/16] libnvdimm: Move nd_numa_attribute_group to device_type To: "Aneesh Kumar K.V" Cc: linux-nvdimm , Ira Weiny , Michael Ellerman , "Oliver O'Halloran" , Vishal Verma , Peter Zijlstra , Dave Hansen , Linux Kernel Mailing List , Linux MM Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 12, 2019 at 10:02 PM Aneesh Kumar K.V wrote: > > On 11/13/19 6:56 AM, Dan Williams wrote: > > On Tue, Nov 12, 2019 at 1:23 AM Aneesh Kumar K.V > > wrote: > >> > >> Dan Williams writes: > >> > >>> A 'struct device_type' instance can carry default attributes for the > >>> device. Use this facility to remove the export of > >>> nd_numa_attribute_group and put the responsibility on the core rather > >>> than leaf implementations to define this attribute. > >>> > >>> Cc: Ira Weiny > >>> Cc: Michael Ellerman > >>> Cc: "Oliver O'Halloran" > >>> Cc: Vishal Verma > >>> Cc: Aneesh Kumar K.V > >>> Signed-off-by: Dan Williams > >> > >> > >> can we also expose target_node in a similar way? This allows application > >> to better understand the node locality of the SCM device. > > > > It is already exported for device-dax instances. See > > DEVICE_ATTR_RO(target_node) in drivers/dax/bus.c. I did not see a use > > case for it to be exported for other nvdimm device types. > > > > some applications do want to access the fsdax namspace as different > mount points based on numa affinity. If can differentiate the two > regions with different target_node and same numa_node, that will help > them better isolate these mounts. Can you be more explicit than "some", and what's the impact if the kernel continues with the status quo and does not export this data? I'm trying to come up with the justification to include into the changelog that adds that information. At least on the pmem platforms I am working with the pmem ranges with different target nodes also appear on different numa nodes so there is no incremental benefit for target node there.