Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1621849pxb; Thu, 4 Feb 2021 18:57:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJwRJaMcL3vsZeo3p5GTJYMbVgqNh6Px2YwLqBO5Ctp89DhvbrOcg4+oKKezXszfuO3Qgdt/ X-Received: by 2002:a17:907:7815:: with SMTP id la21mr1962248ejc.12.1612493831665; Thu, 04 Feb 2021 18:57:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612493831; cv=none; d=google.com; s=arc-20160816; b=EKgEiC94urmIpIT31IKFXfJDCGJiF0UW3g5R4jsFHrd10DFEutoff4PV24B/Y2z59s 69TNo+NH1nCDLq7V4Q7faHp43Wy0JGJ4GqPzskYX7YVoAAYFypQk0wLSbY77r4MKq0Sy QHF6sHzOAj85/4qCuQAdbWHw/h2vg9n3WSfRieg7tQJuZuZIQaQ995+JKT1JYsN4enfk hJuFlpifJYj3rhcfDx/PiEDyzDNSQI5mp7sR3zsixvi6SC5LvB6guko+b/QiRarWprUx /4DcEzCvmSeYoOqhxiLE+eDghqz4ZTGOWiG4qq7iH+u7yPtEhftnLRKWEzJ2bGYubZP8 Lepg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=sdmQZ0I9b44wVQxMMuojt77Q5ebRbY3Ce9uYruPT/N4=; b=oQpvnpf7+qq07bnDFQaaOFApf09h15UV+Z31Cm+s3kQ9wOEGEwtHn6BNk/iVe0hYHd YqujfxptUbXr5uUcbUJ0/dWbQSQZbBbzTjNSl55frK/1bz1Lef4/j+8pIHd6u/+8euER /W/T1Fub+DU5FIluite0KAvvSydIkYNemd3Se1UZox+byKwbh/HNsGpxEUI3wUFHFGrz XekRHQ1S4DPJP89OHaOHX974Xee9ceB16+7MF6u8rGQf2viyhDp7CNBDuLO6QYP6Bvrp HDyePM54cIC+om38BSd0avFgv/uNs2n5dB+txD3+QxJC1ty+MJM6ks7BOn6pEUx6ZVMd UpkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=KA+EwLhB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs28si4607726ejc.141.2021.02.04.18.56.47; Thu, 04 Feb 2021 18:57:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=KA+EwLhB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229692AbhBEC4T (ORCPT + 99 others); Thu, 4 Feb 2021 21:56:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbhBEC4S (ORCPT ); Thu, 4 Feb 2021 21:56:18 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59EC6C0613D6 for ; Thu, 4 Feb 2021 18:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=sdmQZ0I9b44wVQxMMuojt77Q5ebRbY3Ce9uYruPT/N4=; b=KA+EwLhBnICJ36Bwg8niDsOxTi dB7enbqL+7hyA1T8Mb3gNOQKrBCAtfWlznTLwtZ1+9wE7u90C8PSoE1ihUCzJsi3pvwJ/RdZeZ2iV 1F53YqP5B4x4ejA07mHULC5QRcaaJGZaTSeKdx4VEH/D4qVnBMMdL4dqSPfxBPkr7liBsQvSht+ps JQAaSYAP4AJeAyjyI9C8yq74cuo4NH4gFc+/wLjKljEEFFlusBG44UkDxRmJj4+Fga87vWfJxyKtV h57SNEe3itS0dTeGyZb94slitVJpJ4+kORUaDxrtfrMPcJn54GvjFL/OZL/5Jrd9hkxH1iImIy1VH Afu1cYUg==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1l7rHK-001jQP-Jq; Fri, 05 Feb 2021 02:55:29 +0000 Date: Fri, 5 Feb 2021 02:55:26 +0000 From: Matthew Wilcox To: Minchan Kim Cc: Andrew Morton , gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com, LKML , linux-mm Subject: Re: [PATCH] mm: cma: support sysfs Message-ID: <20210205025526.GG308988@casper.infradead.org> References: <20210203155001.4121868-1-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210203155001.4121868-1-minchan@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 03, 2021 at 07:50:01AM -0800, Minchan Kim wrote: > +++ b/mm/Makefile > @@ -106,6 +106,7 @@ obj-$(CONFIG_ZSMALLOC) += zsmalloc.o > obj-$(CONFIG_Z3FOLD) += z3fold.o > obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o > obj-$(CONFIG_CMA) += cma.o > +obj-$(CONFIG_SYSFS) += cma_sysfs.o ehh ... if we have a kernel build with CMA=n, SYSFS=y, we'll get cma_sysfs built in with no cma to report on. > +static ssize_t cma_alloc_attempt_show(struct kobject *kobj, > + struct kobj_attribute *attr, char *buf) > +{ > + unsigned long val; > + struct cma_stat *stat = container_of(kobj, struct cma_stat, kobj); > + > + val = stat->alloc_attempt; > + > + return sysfs_emit(buf, "%lu\n", val); Why not more simply: { struct cma_stat *stat = container_of(kobj, struct cma_stat, kobj); return sysfs_emit(buf, "%lu\n", stat->alloc_attempt); } > + for (i = 0; i < cma_area_count; i++) { > + cma = &cma_areas[i]; > + stat = kzalloc(sizeof(*stat), GFP_KERNEL); > + if (!stat) > + goto out; How many cma areas are there going to be? do we really want to allocate their stat individually?