All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Barry Song <song.bao.hua@hisilicon.com>
Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org,
	andriy.shevchenko@linux.intel.com, linux-kernel@vger.kernel.org,
	dave.hansen@intel.com, linux@rasmusvillemoes.dk,
	rafael@kernel.org, rdunlap@infradead.org, agordeev@linux.ibm.com,
	sbrivio@redhat.com, jianpeng.ma@intel.com,
	valentin.schneider@arm.com, peterz@infradead.org,
	bristot@redhat.com, guodong.xu@linaro.org,
	tangchengchang@huawei.com, prime.zeng@hisilicon.com,
	yangyicong@huawei.com, tim.c.chen@linux.intel.com,
	linuxarm@huawei.com, Tian Tao <tiantao6@hisilicon.com>
Subject: Re: [PATCH v5 1/3] cpumask: introduce cpumap_print_to_buf to support large bitmask and list
Date: Fri, 2 Jul 2021 14:30:34 -0700	[thread overview]
Message-ID: <YN+FemDxyeG+lRTC@yury-ThinkPad> (raw)
In-Reply-To: <20210702092559.8776-2-song.bao.hua@hisilicon.com>

On Fri, Jul 02, 2021 at 09:25:57PM +1200, Barry Song wrote:
> From: Tian Tao <tiantao6@hisilicon.com>
> 
> The existing cpumap_print_to_pagebuf() is used by cpu topology and other
> drivers to export hexadecimal bitmask and decimal list to userspace by
> sysfs ABI.
> 
> Right now, those drivers are using a normal attribute for this kind of
> ABIs. A normal attribute typically has show entry as below:
> 
> static ssize_t example_dev_show(struct device *dev,
>                 struct device_attribute *attr, char *buf)
> {
> 	...
>         return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
> }
> show entry of attribute has no offset and count parameters and this
> means the file is limited to one page only.
> 
> cpumap_print_to_pagebuf() API works terribly well for this kind of
> normal attribute with buf parameter and without offset, count:
> 
> static inline ssize_t
> cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
> {
>         return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
>                                       nr_cpu_ids);
> }
> 
> The problem is once we have many cpus, we have a chance to make bitmask
> or list more than one page. Especially for list, it could be as complex
> as 0,3,5,7,9,...... We have no simple way to know it exact size.
> 
> It turns out bin_attribute is a way to break this limit. bin_attribute
> has show entry as below:
> static ssize_t
> example_bin_attribute_show(struct file *filp, struct kobject *kobj,
>              struct bin_attribute *attr, char *buf,
>              loff_t offset, size_t count)
> {
>         ...
> }
> 
> With the new offset and count parameters, this makes sysfs ABI be able
> to support file size more than one page. For example, offset could be
> >= 4096.
> 
> This patch introduces cpumap_print_to_buf() so that those drivers can
> move to bin_attribute to support large bitmask and list. In result,
> we have to pass the corresponding parameters from bin_attribute to this
> new API.
> 
> Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
> Cc: Yury Norov <yury.norov@gmail.com>
> Cc: Valentin Schneider <valentin.schneider@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> ---
>  include/linux/cpumask.h | 19 +++++++++++++++++++
>  lib/cpumask.c           | 18 ++++++++++++++++++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index bfc4690de4f4..24f410a2e793 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -983,6 +983,25 @@ cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
>  				      nr_cpu_ids);
>  }
>  
> +/**
> + * cpumap_print_to_buf  - copies the cpumask into the buffer either
> + *      as comma-separated list of cpus or hex values of cpumask;
> + *      Typically used by bin_attribute to export cpumask bitmask and
> + *      list ABI.
> + * @list: indicates whether the cpumap must be list
> + *      true:  print in decimal list format
> + *      fasle: print in hexadecimal bitmask format
> + * @mask: the cpumask to copy
> + * @buf: the buffer to copy into
> + * @off: in the string from which we are copying, We copy to @buf
> + * @count: the maximum number of bytes to print
> + *
> + * Returns the length of how many bytes have been copied.
> + */
> +extern ssize_t
> +cpumap_print_to_buf(bool list, char *buf, const struct cpumask *mask,
> +		    loff_t off, size_t count);
> +
>  #if NR_CPUS <= BITS_PER_LONG
>  #define CPU_MASK_ALL							\
>  (cpumask_t) { {								\
> diff --git a/lib/cpumask.c b/lib/cpumask.c
> index c3c76b833384..40421a6d31bc 100644
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
> @@ -279,3 +279,21 @@ int cpumask_any_distribute(const struct cpumask *srcp)
>  	return next;
>  }
>  EXPORT_SYMBOL(cpumask_any_distribute);
> +
> +ssize_t cpumap_print_to_buf(bool list, char *buf, const struct cpumask *mask,
> +		    loff_t off, size_t count)
> +{
> +	const char *fmt = list ? "%*pbl\n" : "%*pb\n";
> +	ssize_t size;
> +	void *data;
> +
> +	data = kasprintf(GFP_KERNEL, fmt, nr_cpu_ids, cpumask_bits(mask));
> +	if (!data)
> +		return -ENOMEM;
> +
> +	size = memory_read_from_buffer(buf, count, &off, data, strlen(data) + 1);
> +	kfree(data);

Barry,

It looks like my comments for previous iteration were ignored. I don't
like the approach where you allocate potentially big amount of kernel
memory just to free it almost immediately. Nor in lib/bitmap, neither
in lib/cpumask.

For next iterations, please move this function back to lib/bitmap
because there's no specific here for cpumasks.

Thaks,
Yury

> +	return size;
> +}
> +EXPORT_SYMBOL(cpumap_print_to_buf);
> -- 
> 2.25.1

  parent reply	other threads:[~2021-07-02 21:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02  9:25 [PATCH v5 0/3] use bin_attribute to break the size limitation of cpumap ABI Barry Song
2021-07-02  9:25 ` [PATCH v5 1/3] cpumask: introduce cpumap_print_to_buf to support large bitmask and list Barry Song
2021-07-02 10:07   ` Andy Shevchenko
2021-07-02 21:30   ` Yury Norov [this message]
2021-07-03  8:23     ` Song Bao Hua (Barry Song)
2021-07-02  9:25 ` [PATCH v5 2/3] topology: use bin_attribute to break the size limitation of cpumap ABI Barry Song
2021-07-02 12:54   ` kernel test robot
2021-07-02 12:54     ` kernel test robot
2021-07-02 16:33   ` kernel test robot
2021-07-02 16:33     ` kernel test robot
2021-07-02  9:25 ` [PATCH v5 3/3] drivers/base/node.c: " Barry Song
2021-07-02 10:03   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YN+FemDxyeG+lRTC@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bristot@redhat.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guodong.xu@linaro.org \
    --cc=jianpeng.ma@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxarm@huawei.com \
    --cc=peterz@infradead.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sbrivio@redhat.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tangchengchang@huawei.com \
    --cc=tiantao6@hisilicon.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=valentin.schneider@arm.com \
    --cc=yangyicong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.