Received: by 2002:ac0:8c8e:0:0:0:0:0 with SMTP id r14csp1172547ima; Wed, 6 Feb 2019 15:10:49 -0800 (PST) X-Google-Smtp-Source: AHgI3IZzNGrfCubP8VC966l3bfZyxYpXqsOlQlucSHyMH0cRrWKG5i/S6XClk6BBzSMhkUL0Ftz6 X-Received: by 2002:a62:2702:: with SMTP id n2mr13301929pfn.29.1549494649748; Wed, 06 Feb 2019 15:10:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549494649; cv=none; d=google.com; s=arc-20160816; b=Xicsr76AI8gziCPPUJtjeVpxAcbyXUAwIfEUil6V1XYHMk2ivqxeEnOofaHz5NbqLF I8MMmFn6od68hoLVx5vedI/rePdwoHSKNOKuXyBwwAryzFlfM0xdzlyCeZkpfIJQ57nw PGT/Y47+xy771/XWF4tyxR2eEK6dcyHLqq0Glgwf99yGSdN9N81obxFNx27oF2g8XI9+ bFJglAXRfYO7w+eEU1vctBIMltS4viNRhLTGevF19qsQBTcBO3y1GsveyQj4/dsPY4+1 nn275hRZQ4KSHKlgXbZovgWk1H+Bj6KZqG43DFbl6yqBm+2qRYtgVa7v3zo48odkYao4 L5Tw== 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; bh=ukbSF038uA8QdrAcMJjMRBbSncavGnnI8nn400E+/YQ=; b=hFC7aGF8TSU7jMbsbDTJ2aPP+HgXHsYjIgE/QOEminUVxD4H0Wi73FgHEbianku6Dr GEbBjDKhvggtzkHkZPZcT2pBau37viF0dEcwTIclWGso5MkP0BeU9ZIw7lV/qVig3wdR DnPe5kT66cJ8RLbBZLec+voMaptVR9qWyfV7046szij7d+yZiEpNevnbrrwHf02H3YuT PafBU3XjUWbY2WqOr+FF4VGN5eaa0JGpdjKfjQ29VRlkZ46kURY0ZHEHEeHZ11tRR2i3 b+MfNF4PGhNIoKaL7/1vmga7TxMMNsjbX7qh4nFTdGceXcFOZJ2bbB9TeZYZCBR/q2+x +NMA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m14si7087716pgd.326.2019.02.06.15.10.34; Wed, 06 Feb 2019 15:10:49 -0800 (PST) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726610AbfBFXKZ (ORCPT + 99 others); Wed, 6 Feb 2019 18:10:25 -0500 Received: from mga03.intel.com ([134.134.136.65]:11649 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726062AbfBFXKZ (ORCPT ); Wed, 6 Feb 2019 18:10:25 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2019 15:10:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,342,1544515200"; d="scan'208";a="273061511" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga004.jf.intel.com with ESMTP; 06 Feb 2019 15:10:23 -0800 Date: Wed, 6 Feb 2019 16:09:53 -0700 From: Keith Busch To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , ACPI Devel Maling List , Linux Memory Management List , Dave Hansen , Dan Williams Subject: Re: [PATCHv5 04/10] node: Link memory nodes to their compute nodes Message-ID: <20190206230953.GB30221@localhost.localdomain> References: <20190124230724.10022-1-keith.busch@intel.com> <20190124230724.10022-5-keith.busch@intel.com> <20190205145227.GG17950@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 05, 2019 at 04:17:09PM +0100, Rafael J. Wysocki wrote: > wrote: > > > > When you use a "raw" kobject then userspace tools do not see the devices > > and attributes in libraries like udev. > > And why would they need it in this particular case? > > > So unless userspace does not care about this at all, > > Which I think is the case here, isn't it? > > > you should use a 'struct device' where ever > > possible. The memory "savings" usually just isn't worth it unless you > > have a _lot_ of objects being created here. > > > > Who is going to use all of this new information? > > Somebody who wants to know how the memory in the system is laid out AFAICS. Yes, this is for user space to make informed decisions about where it wants to allocate/relocate hot and cold data with respect to particular compute domains. So user space should care about these attributes, and they won't always be static when memory hotplug support for these attributes is added. Does that change anything, or still recommending kobject? I don't have a strong opinion either way and have both options coded and ready to submit new version once I know which direction is most acceptable.