Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp45757pxf; Wed, 24 Mar 2021 20:29:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEpcwpVgTqS9nPdc5Y5JJRFaxCj6qkw9d0VaummZFHvtZkrdmOZ4Fipkyiyook9AU2d2ea X-Received: by 2002:aa7:d5c9:: with SMTP id d9mr7076555eds.102.1616642970595; Wed, 24 Mar 2021 20:29:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616642970; cv=none; d=google.com; s=arc-20160816; b=D0MuBh5jXvGIhgNIAKk7Qgfr6GKQFZOKIErCW+zd5/2k+Fw3c7ZFt6ohoHt1/dqGGu km+EyPvNFO3CvULc4luH9JlHWjDv0HQuvimerH0iD5/palvYiRjhYXIG/wi7SsKj2eyT H4uUsI8Da61Zvf7JDFoePSntmKrIHhGmouQjZ7j16ZREvktfsYUTi4SLAp30e3AXkv/u hLiRZ6/Ez2DbCP8sGheDfDQxk4EDZmzmTo8h42vWvobx8RN50rKD+uKHzBhLJiRwLZb9 xj0yIdnpyK0PBY9DIUs6Y5CQYHdP0Fli8ASaFQVihCFUN5gDyesUQIkL+0ovE628pose KyBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=GXCHwCjIojzQra6Ybo8a6ubZkkqtpIUTfy1bdb9pub8=; b=b7sinKSpKMek2heuKyRH9U80IHw+Xf6urcr60NcSH3iH4am+RxdPQIohUj8q3OmYmH iuRI+1GKOzs29U/BCuEXoHxkjW+aFF3x4E4xXD35+jBY+ALLS6hP07sH/gbuwaAyDBo4 JESHZ3qFcqQZip2zXD2ycY9uDts0v9WA7zewZFIzl+AqQV0CFzIim2fMbAkBEUhNfIc5 BOAoIoAbEFUS3QDRraj3+cpms9/q9I/CrHkJhmKBguW7IfjpYovaaQzJF/V4Y+mnwVdk AlCw046ee90q5iVo7cxD8DjGwmImSfVjsO4jIrKYQJ8mGVEZakv3TuLE5AZcRpdPG29U /CXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lrwPb0Ow; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lt12si3201447ejb.158.2021.03.24.20.29.07; Wed, 24 Mar 2021 20:29:30 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=lrwPb0Ow; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238445AbhCXVcO (ORCPT + 99 others); Wed, 24 Mar 2021 17:32:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238489AbhCXVbz (ORCPT ); Wed, 24 Mar 2021 17:31:55 -0400 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59E39C06174A for ; Wed, 24 Mar 2021 14:31:54 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id s17so487934ljc.5 for ; Wed, 24 Mar 2021 14:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GXCHwCjIojzQra6Ybo8a6ubZkkqtpIUTfy1bdb9pub8=; b=lrwPb0OwRuF4bqws2EJVVX5j0uiXIFTIr2bAgHN/bzUHYfymLk2LM7VDU3LXmidK0i bXBwWghuY/RV0QdKb7L8MAAwIiU43qvbC2j3VUGxWhINR97vi0mClUWlb0ugOuvrxVhg 7yuaV32pEYwNNMeqBAWYrcA7z5P3Df43dTILzg41SoOUOsqOlSJfc599iONwRuVBj34Q BAMm3RiVw7hYomiB9gt5kUyXp3qNlW4MOKyrfynVuNeC/FrMV0oCSAgbNTNJLB48wzD5 aU46LmJe7lbhAxidq8v3T7oj1diu1Qh7UcoP0B2Cn96LwMxVq1tnOCja0Vb0D9ILq17d 6Fxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GXCHwCjIojzQra6Ybo8a6ubZkkqtpIUTfy1bdb9pub8=; b=MmUAr/cWfxAL1oPLmsJXVsjVBfFLtpDFTi9wLIWvXTqnEE3mbJFP7tFoQ0CY1Kz2Jh v/eRFWmivTlJVdiiE0275nVf1zYFzgNm2/RcOdJJxTe8AJQ0PalBswBIgEvZiK8hSJ7s Ows1hCuSdYgRQ/rriF07QT1HLQWuddvHsP1ISNgJkXpXy94H5moprZei5+hduIZfJD2N ayGDiFmRWoXw1+xvkuN+zv9zS+DpBJH/jcvRltdUo+OcAWTCwjA2XpTZQGc0YMYfxhJ0 hJyFbntFWoKRjmyYxeHzUkHnIZw5npHUmmste7vyLCcMb2AkMk7lgzK2hKJdf/MVT4Cv v1jw== X-Gm-Message-State: AOAM530TRZAfoSY3FqxKTzTHQugmSbinXKmQfd9FOYsn7Cyb1tRbrwNx naWAJfwTEGGLNUlfJXSpnQU= X-Received: by 2002:a2e:700a:: with SMTP id l10mr3362086ljc.368.1616621512815; Wed, 24 Mar 2021 14:31:52 -0700 (PDT) Received: from [192.168.2.145] (109-252-193-60.dynamic.spd-mgts.ru. [109.252.193.60]) by smtp.googlemail.com with ESMTPSA id u9sm444852ljd.130.2021.03.24.14.31.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Mar 2021 14:31:52 -0700 (PDT) Subject: Re: [PATCH v7] mm: cma: support sysfs To: Minchan Kim , Andrew Morton Cc: linux-mm , LKML , gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com, jhubbard@nvidia.com, willy@infradead.org, Colin Ian King References: <20210324205503.2132082-1-minchan@kernel.org> From: Dmitry Osipenko Message-ID: <65840bfd-4471-7c8d-ce71-c4705baf3bfe@gmail.com> Date: Thu, 25 Mar 2021 00:31:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210324205503.2132082-1-minchan@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 24.03.2021 23:55, Minchan Kim пишет: > Since CMA is getting used more widely, it's more important to > keep monitoring CMA statistics for system health since it's > directly related to user experience. > > This patch introduces sysfs statistics for CMA, in order to provide > some basic monitoring of the CMA allocator. > > * the number of CMA page successful allocations > * the number of CMA page allocation failures > > These two values allow the user to calcuate the allocation > failure rate for each CMA area. > > e.g.) > /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail] > /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail] > /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail] > > The cma_stat was intentionally allocated by dynamic allocation > to harmonize with kobject lifetime management. > https://lore.kernel.org/linux-mm/YCOAmXqt6dZkCQYs@kroah.com/ > > Reported-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko > Suggested-by: Dmitry Osipenko The tags are incorrect, I haven't suggested this change. > Suggested-by: John Hubbard > Suggested-by: Matthew Wilcox > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: John Hubbard > Addresses-Coverity: ("Dereference after null check") There are no dereferences fixed by this patch. > Signed-off-by: Colin Ian King > Signed-off-by: Minchan Kim > --- ... > #include > +#include > + > +struct cma_kobject { > + struct cma *cma; > + struct kobject kobj; If you'll place the kobj as the first member of the struct, then container_of will be a no-op. ... > +#include > +#include > +#include > + > +#include "cma.h" > + > +void cma_sysfs_account_success_pages(struct cma *cma, unsigned long nr_pages) > +{ > + atomic64_add(nr_pages, &cma->nr_pages_succeeded); > +} > + > +void cma_sysfs_account_fail_pages(struct cma *cma, unsigned long nr_pages) > +{ > + atomic64_add(nr_pages, &cma->nr_pages_failed); > +} > + > +#define CMA_ATTR_RO(_name) \ > + static struct kobj_attribute _name##_attr = __ATTR_RO(_name) nit: #defines and inlined helpers typically are placed at the top of the code, after includes. > +static inline struct cma *cma_from_kobj(struct kobject *kobj) > +{ > + struct cma_kobject *cma_kobj = container_of(kobj, struct cma_kobject, > + kobj); > + struct cma *cma = cma_kobj->cma; > + > + return cma; nit: you can write this as: return container_of(kobj, struct cma_kobject, kobj)->cma; > +} > + > +static ssize_t alloc_pages_success_show(struct kobject *kobj, > + struct kobj_attribute *attr, char *buf) > +{ > + struct cma *cma = cma_from_kobj(kobj); > + > + return sysfs_emit(buf, "%llu\n", > + atomic64_read(&cma->nr_pages_succeeded)); nit: Algnment isn't right, should be better to write it as single line, IMO. ... > +static int __init cma_sysfs_init(void) > +{ > + struct kobject *cma_kobj_root; > + struct cma_kobject *cma_kobj; > + struct cma *cma; > + int i, err; > + > + cma_kobj_root = kobject_create_and_add("cma", mm_kobj); > + if (!cma_kobj_root) > + return -ENOMEM; > + > + for (i = 0; i < cma_area_count; i++) { > + cma_kobj = kzalloc(sizeof(*cma_kobj), GFP_KERNEL); > + if (!cma_kobj) { > + err = -ENOMEM; > + goto out; > + } > + > + cma = &cma_areas[i]; > + cma->cma_kobj = cma_kobj; > + cma_kobj->cma = cma; > + err = kobject_init_and_add(&cma_kobj->kobj, &cma_ktype, > + cma_kobj_root, "%s", cma->name); nit: Previousy algnment of the code was better here. Otherwise this is okay to me: Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko