Message-ID: <4ab537937f344893bf5bdcb13e46ce04@hisilicon.com>
Date:   Mon, 19 Jul 2021 11:10:45 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        Yury Norov <yury.norov@...il.com>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "sbrivio@...hat.com" <sbrivio@...hat.com>,
        "jianpeng.ma@...el.com" <jianpeng.ma@...el.com>,
        "valentin.schneider@....com" <valentin.schneider@....com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "guodong.xu@...aro.org" <guodong.xu@...aro.org>,
        tangchengchang <tangchengchang@...wei.com>,
        "Zengtao (B)" <prime.zeng@...ilicon.com>,
        yangyicong <yangyicong@...wei.com>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        Linuxarm <linuxarm@...wei.com>,
        "tiantao (H)" <tiantao6@...ilicon.com>
Subject: RE: [PATCH v7 2/4] topology: use bin_attribute to break the size
 limitation of cpumap ABI



> -----Original Message-----
> From: andriy.shevchenko@...ux.intel.com
> [mailto:andriy.shevchenko@...ux.intel.com]
> Sent: Monday, July 19, 2021 9:07 PM
> To: Yury Norov <yury.norov@...il.com>
> Cc: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>;
> gregkh@...uxfoundation.org; akpm@...ux-foundation.org;
> linux-kernel@...r.kernel.org; dave.hansen@...el.com;
> linux@...musvillemoes.dk; rafael@...nel.org; rdunlap@...radead.org;
> agordeev@...ux.ibm.com; sbrivio@...hat.com; jianpeng.ma@...el.com;
> valentin.schneider@....com; peterz@...radead.org; bristot@...hat.com;
> guodong.xu@...aro.org; tangchengchang <tangchengchang@...wei.com>; Zengtao (B)
> <prime.zeng@...ilicon.com>; yangyicong <yangyicong@...wei.com>;
> tim.c.chen@...ux.intel.com; Linuxarm <linuxarm@...wei.com>; tiantao (H)
> <tiantao6@...ilicon.com>
> Subject: Re: [PATCH v7 2/4] topology: use bin_attribute to break the size
> limitation of cpumap ABI
> 
> On Fri, Jul 16, 2021 at 06:12:21PM -0700, Yury Norov wrote:
> > On Sat, Jul 17, 2021 at 12:16:48AM +0000, Song Bao Hua (Barry Song) wrote:
> > > > From: Yury Norov [mailto:yury.norov@...il.com]
> > > > Sent: Saturday, July 17, 2021 8:04 AM
> > > > On Fri, Jul 16, 2021 at 08:49:58AM +0000, Song Bao Hua (Barry Song) wrote:
> 
> ...
> 
> > > Generally good idea. However, for sysfs ABI entries, it might not be
> > > that true.
> > >
> > > A sysfs entry might never be read for its whole life. As I explained
> > > before, a sysfs entry - especially for list,  is randomly "cat" by users.
> > > Many of them won't be read forever. And after they are read once, they
> > > will probably never be read again. The operations to read ABI could be
> > > random and rare. Performance wouldn't be a concern.
> > >
> > > To avoid holding the memory which might never be used, it is better to
> > > allocate and free the memory during runtime. I mean to allocate in show()
> > > and free in show(), aka, to do it on demand.
> > >
> > > For example, for a server with 256CPU and each cpu has dozens of sysfs ABI
> > > entries, only a few of sysfs list entries might be randomly "cat" by users.
> > > Holding 256*entries memory doesn't look good.
> >
> > Ok, makes sense.
> >
> > > > This would require to add bitmap_max_string_size(list, bitmap, nbits),
> > > > but it's O(1), and I think, others will find it helpful.
> > >
> > > What about getting size and memory at the same time?
> >
> > 1. We already have kasprintf()
> > 2. It breaks coding style.
> >
> > Documentation/process/coding-style.rst:
> >         Functions should be short and sweet, and do just one thing.
> >
> > From practical point of view, there should be some balance between
> > granularity and ease-of-use. But in this case, bitmap_list cries for
> > a function that will help to estimate size of output buffer.
> 
> According to the vsnprintf() logic the estimated size is what it returns. If
> user supplies too few bytes available, the comparison with the returned value
> can tell caller that space wasn't big enough.

As far as my understanding, for estimated size in bitmap_max_string_size()
Yury might mean something as below?

* For bitmask:
Each 32bit needs 9 bytes "11111111,", so the max size of mask would be:
9*nr_cpus / 32 ?

* For list:
Maximally  cpu0-9 need 2bytes, like "1,"
Maximally cpu10-99 need 3bytes, like "50,"
Maximally cpu100-999 need 4bytes, like "101,"
Maximally cpu1000-9999 need 5 bytes..
 
So once we know the size of the bitmap, we can figure out the maximum
size of its string for mask and list?

Pls correct me if you don't mean this, yury.


> 
> > And it's
> > easy to imagine a case where the estimated length of bitmap is needed
> > explicitly:
> >
> >         size_t max_size = bitmap_max_string_size(nbits);
> >         char *buf = kmalloc(PAGE_ALIGN(max_size) * nr_cpus);
> >
> > Thought, I don't insist. In your driver you can do:
> >
> >         size_t size = snprintf(NULL, 0, ...);
> >         void *buf = kmalloc(size);
> >
> > It will be fully correct, and you already have everything you need.
> >
> > > ssize_t bitmap_get_print_buf(bool list, char **buf, const unsigned long
> > >  *maskp, int nmaskbits)
> > >
> > > ssize_t cpumap_get_print_buf(bool list, char **buf, const struct cpumask
> *mask);
> > >
> > > This API returns the size of printed buffer, and it also gets the
> > > printed result saved in *buf. Then drivers don't need to do three
> > > steps:
> > >
> > > 1. get cpumap buffer size which is your cpumap_max_string_size()
> > > 2. allocate memory for buffer according to size got in step 1
> > > 3. print bitmap(cpumap) to buffer by "pbl"
> > >
> > > It will only need to call bitmap_get_print_buf() and all three
> > > things are done inside bitmap_get_print_buf().
> > >
> > > How to use the size and memory allocated in cpumap_get_print_buf
> > > will be totally up to users.
> > >
> > > The other benefit for this is that if we get string size during initialization,
> > > and then we print in show() entries, the size got at the beginning might
> be not
> > > enough as system topology might have changed. Sysfs ABI reflects the status
> of
> > > system at this moment.
> 
> --
> With Best Regards,
> Andy Shevchenko
> 

Thanks
Barry

Powered by blists - more mailing lists