Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp5130188ima; Tue, 5 Feb 2019 06:52:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IY321xgt9z6lDxFmwd6N3qUEiagOF3DMUR8KNV/EwXnarZlR+6tIxoVLjVQsW2J2SljhsjG X-Received: by 2002:a62:7792:: with SMTP id s140mr5398684pfc.26.1549378373911; Tue, 05 Feb 2019 06:52:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549378373; cv=none; d=google.com; s=arc-20160816; b=xwRjkaIZxBTKxxjR7xHawLFvQc+3lVBFTk/GgQtVksPdmpOmXYoIxF0R2lDgMa3Apq 0kb8N6QfDTEZwDK6uVkxY0CSfGBvOVwj4FCWM2L8aj5s9zWxKQBQ3zVIFjJKrPDf46x2 6wkKmUHYFsIvSF023bwIXvuQziRgn0bo+0Px5xrcrjyQptO3MD+RDk3HdFaJH6w/Y4b2 MgIYvYYOt/CyKBqPYvW5ob33+uQ/ESPU0rt5Q2BTPa+kXiIlCj5FXpbRuWMOfHLMy789 eb6bhBssMWDl7VuWw2BWe6t00Kik0pxtwW7zJ/vy1y6fTmSq28/hBWncOX0mxfeT/Rww cDyg== 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; bh=4ALa6k0hESH6jdS/pdhP9yR2oZJ8c6TLMwwa6JY+fcY=; b=atwdkpMNVMGkTnoL8KOnm9uKWxmNduY7MJa2LMhLtnrt3BA7zJtCon3pdCmuldy+/k /mrBYYw8fj3CJ4jpCitUZ/aWgPgvNldJKp8IMlKvuTQQmABFRK5WASsNSU43WynEtfWH R5M1bJ7xee+ZbLusSzeqhPKVKeOn06qNb2LBSzqzSgCY6ag90IerCTN6Qrh70GZFMxwN PyH8q+BrmDL2PwbYG20JQ73cspuwBF3B7+XGmIjENlnYGnULoZMPn/ehcUevPeC5AiTV T3oxLc4t62ypDNS7duyYXTbSv9rLbd8fj6n5HZFpTKh0SdQX5IMQLLbh2l6z3O3SbFAH DiiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ovmq7q3y; 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 p189si3544443pfb.0.2019.02.05.06.52.36; Tue, 05 Feb 2019 06:52:53 -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; dkim=pass header.i=@kernel.org header.s=default header.b=ovmq7q3y; 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 S1727352AbfBEOwb (ORCPT + 99 others); Tue, 5 Feb 2019 09:52:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:34042 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbfBEOwb (ORCPT ); Tue, 5 Feb 2019 09:52:31 -0500 Received: from localhost (unknown [212.187.182.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 244062081B; Tue, 5 Feb 2019 14:52:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549378350; bh=YYosVEfjw34D+TtsvSvjOuSr//0DVVoCCC0u5tckTSg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ovmq7q3ygf3dUZSvld8v98BmehEcCgKjFOy0jqxgyBxS6+WMOCV/6hMgE5l/hdHxv Xm+TqVPW5KvDFspngtv9FTADycQDVU5Kw5mOat15bNfnYd1E5j1jQHoMpabShuQjoC 33/u7zZk3rYPncQDjznRJQ0EdO4oOXMQHanHU5J4= Date: Tue, 5 Feb 2019 15:52:27 +0100 From: Greg Kroah-Hartman To: "Rafael J. Wysocki" Cc: Keith Busch , 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: <20190205145227.GG17950@kroah.com> References: <20190124230724.10022-1-keith.busch@intel.com> <20190124230724.10022-5-keith.busch@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) 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 01:33:27PM +0100, Rafael J. Wysocki wrote: > > +/** > > + * struct node_access_nodes - Access class device to hold user visible > > + * relationships to other nodes. > > + * @dev: Device for this memory access class > > + * @list_node: List element in the node's access list > > + * @access: The access class rank > > + */ > > +struct node_access_nodes { > > + struct device dev; > > I'm not sure if the entire struct device is needed here. > > It looks like what you need is the kobject part of it only and you can > use a kobject directly here: > > struct kobject kobj; > > Then, you can register that under the node's kobject using > kobject_init_and_add() and you can create attr groups under a kobject > using sysfs_create_groups(), which is exactly what device_add_groups() > does. > > That would allow you to avoid allocating extra memory to hold the > entire device structure and the extra empty "power" subdirectory added > by device registration would not be there. When you use a "raw" kobject then userspace tools do not see the devices and attributes in libraries like udev. So unless userspace does not care about this at all, 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? thanks, greg k-h