Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 01:23, John Hubbard пишет:
> On 3/24/21 3:11 PM, Dmitry Osipenko wrote:
>> 25.03.2021 01:01, John Hubbard пишет:
>>> On 3/24/21 2:31 PM, Dmitry Osipenko wrote:
...
> +#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.
>>>
>>> However, *this does not matter*. Let's not get carried away. If
>>> container_of() ends up as a compile-time addition of +8, instead
>>> of +0, there is not going to be a visible effect in the world.
>>> Or do you have some perf data to the contrary?
>>>
>>> Sometimes these kinds of things matter. But other times, they are
>>> just pointless to fret about, and this is once such case.
>>
>> Performance is out of question here, my main point is about maintaining
>
> In that case, there is even less reason to harass people about the order
> of members of a struct.
>
>> a good coding style. Otherwise there is no point in not embedding kobj
>> into cma struct as well, IMO.
>
>
> We really don't need to worry about the order of members in a struct,
> from a "coding style" point of view. It is a solid step too far.
>
> Sorry if that sounds a little too direct. But this review has tended to
> go quite too far into nitpicks that are normally left as-is, and I've
> merely picked one that is particularly questionable. I realize that other
> coding communities have their own standards. Here, I'm explaining what
> I have observed about linux-mm and linux-kernel, which needs to be
> respected.
I tried to help as much as I could, sorry if this felt annoying to you
or anyone else.
I assume that linux-mm maintainers, like any other maintainers, should
skip all suggestions that are deemed as inappropriate to them.
Re: [PATCH v7] mm: cma: support sysfs
On 3/24/21 3:11 PM, Dmitry Osipenko wrote:
25.03.2021 01:01, John Hubbard пишет:
On 3/24/21 2:31 PM, Dmitry Osipenko wrote:
...
+#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.
However, *this does not matter*. Let's not get carried away. If
container_of() ends up as a compile-time addition of +8, instead
of +0, there is not going to be a visible effect in the world.
Or do you have some perf data to the contrary?
Sometimes these kinds of things matter. But other times, they are
just pointless to fret about, and this is once such case.
Performance is out of question here, my main point is about maintaining
In that case, there is even less reason to harass people about the order
of members of a struct.
a good coding style. Otherwise there is no point in not embedding kobj
into cma struct as well, IMO.
We really don't need to worry about the order of members in a struct,
from a "coding style" point of view. It is a solid step too far.
Sorry if that sounds a little too direct. But this review has tended to
go quite too far into nitpicks that are normally left as-is, and I've
merely picked one that is particularly questionable. I realize that other
coding communities have their own standards. Here, I'm explaining what
I have observed about linux-mm and linux-kernel, which needs to be respected.
thanks,
--
John Hubbard
NVIDIA
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 00:55, Minchan Kim пишет: >> The tags are incorrect, I haven't suggested this change. > During the development, you have suggested many things > to make it clean. That suggested-by couldn't represent > all the detail but wanted to give credit for you, too > since you spent the time to make it better. > > Okay, since you didn't like it, I will remove it. > That's what the r-b tag is for, the suggested-by is about suggesting the patch in general. Looking forward to the final v8, thank you for yours efforts!
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 00:55, Minchan Kim пишет:
>>> +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.
> Let me make it align rather than single line since I know someone
> who keep asking us to not overflow 80 columns unless it's special.
>
I'm actually one of those guys who complains about 80 chars (where
necessary), but in this particular case it only hurts readability of the
code, IMO.
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 01:10, Dmitry Osipenko пишет: > 25.03.2021 00:55, Minchan Kim пишет: >>> There are no dereferences fixed by this patch. >> Let me add this: >> https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/ >> > > The tag is invalid now, since you squashed the fix. I think you may add > "Co-developed-by: Colin Ian King ", but this > also should require to add the s-b from Colin, if he doesn't mind. > Ah, I now see that the s-b tag is already there.
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 01:01, John Hubbard пишет:
> On 3/24/21 2:31 PM, Dmitry Osipenko wrote:
>> ...
>>> +#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.
>>
>
> However, *this does not matter*. Let's not get carried away. If
> container_of() ends up as a compile-time addition of +8, instead
> of +0, there is not going to be a visible effect in the world.
> Or do you have some perf data to the contrary?
>
> Sometimes these kinds of things matter. But other times, they are
> just pointless to fret about, and this is once such case.
Performance is out of question here, my main point is about maintaining
a good coding style. Otherwise there is no point in not embedding kobj
into cma struct as well, IMO.
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 00:55, Minchan Kim пишет: >> There are no dereferences fixed by this patch. > Let me add this: > https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/ > The tag is invalid now, since you squashed the fix. I think you may add "Co-developed-by: Colin Ian King ", but this also should require to add the s-b from Colin, if he doesn't mind.
Re: [PATCH v7] mm: cma: support sysfs
On 3/24/21 2:31 PM, Dmitry Osipenko wrote:
...
+#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.
However, *this does not matter*. Let's not get carried away. If
container_of() ends up as a compile-time addition of +8, instead
of +0, there is not going to be a visible effect in the world.
Or do you have some perf data to the contrary?
Sometimes these kinds of things matter. But other times, they are
just pointless to fret about, and this is once such case.
thanks,
--
John Hubbard
NVIDIA
Re: [PATCH v7] mm: cma: support sysfs
On Thu, Mar 25, 2021 at 12:31:51AM +0300, Dmitry Osipenko wrote:
> 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/ycoamxqt6dzkc...@kroah.com/
> >
> > Reported-by: Dmitry Osipenko
> > Tested-by: Dmitry Osipenko
> > Suggested-by: Dmitry Osipenko
>
> The tags are incorrect, I haven't suggested this change.
During the development, you have suggested many things
to make it clean. That suggested-by couldn't represent
all the detail but wanted to give credit for you, too
since you spent the time to make it better.
Okay, since you didn't like it, I will remove it.
>
> > 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.
Let me add this:
https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/
>
> > 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.
Cool.
>
> ...
> > +#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.
No problem since I should resend anyway.
>
> > +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;
Better.
>
> > +}
> > +
> > +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.
Let me make it align rather than single line since I know someone
who keep asking us to not overflow 80 columns unless it's special.
>
> ...
> > +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.
Yub.
>
> Otherwise this is okay to me:
>
> Reviewed-by: Dmitry Osipenko
> Tested-by: Dmitry Osipenko
Thanks!
Re: [PATCH v7] mm: cma: support sysfs
25.03.2021 00:31, Dmitry Osipenko пишет: >> Reported-by: Dmitry Osipenko >> Tested-by: Dmitry Osipenko >> Suggested-by: Dmitry Osipenko > The tags are incorrect, I haven't suggested this change. The reported-by also should be removed.
Re: [PATCH v7] mm: cma: support sysfs
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/ycoamxqt6dzkc...@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
