linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Vasily Averin <vvs@virtuozzo.com>, Roman Gushchin <guro@fb.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Shakeel Butt <shakeelb@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: tools/cgroup/memcg_slabinfo.py is broken
Date: Mon, 21 Feb 2022 10:19:16 +0100	[thread overview]
Message-ID: <00ca9ac6-0fd5-7cd1-7511-406eda292af3@suse.cz> (raw)
In-Reply-To: <11060a75-98c2-f547-68eb-fcab404a2539@virtuozzo.com>

On 2/21/22 06:17, Vasily Averin wrote:
> On 17.02.2022 03:51, Roman Gushchin wrote:
>> On Thu, Feb 17, 2022 at 12:13:53AM +0000, Matthew Wilcox wrote:
>>> On Wed, Feb 16, 2022 at 03:57:39PM -0800, Shakeel Butt wrote:
>>>> On Wed, Feb 16, 2022 at 3:12 PM Matthew Wilcox <willy@infradead.org> wrote:
>>>>>
>>>> [...]
>>>>>> Here I'd keep _page (or _folio, if you want), because
>>>>>> it makes it clear that the function goes over all pages
>>>>>> (and is expensive therefore).
>>>>>
>>>>> But there's no intrinsic reason that it should.  If that's a
>>>>> performance problem, you could keep slabs on a separate list
>>>>> from, eg, file or anon memory.
>>>>>
>>>>
>>>> Is there enough space in the struct slab for that list or do you mean
>>>> something different?
>>>
>>> Well, I don't know what data structure your for_each_page() uses, so
>>> I don't know what to suggest exactly.
>>>
>>> If it's an iteration over the entirety of memmap, then maybe you'd
>>> rather iterate over each kmem_cache like /proc/slabinfo does?
>>
>> Anyway, here is v2. I hope you're fine with it.
> 
> It works well on my test node,
> Tested-by: Vasily Averin <vvs@virtuozzo.com>

Thanks all for fixing and testing!

> Andrew,
> this script was created in August 2020, broken in few months, repaired in
> April 2021,
> then broken again in October 2021 and I hope will be repaired soon.

Since it was me who broke it now in 5.17-rc1 and it's slab related, I'd take
the fix to slab tree and send to Linus so it's in 5.17 final.

> I think it would be useful to add smoke test with this script into checks
> of some build robots.
> 
> Could you please advise how to do it?

I guess ask the lkp maintainers?

BTW I'm a bit skeptical in general about maintaining drgn (or gdb) based
python scriplets within the kernel tree, that are supposed to work only with
that specific version. The model of the 'crash' tool which supports a range
of kernels seems more practical and sustainable to me.


  parent reply	other threads:[~2022-02-21  9:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 13:22 tools/cgroup/memcg_slabinfo.py is broken Vasily Averin
2022-02-15 23:29 ` Roman Gushchin
     [not found]   ` <35486a00-791c-3b1b-14e0-476e6242709b@virtuozzo.com>
     [not found]     ` <Yg1kFH3umdrvOhu1@carbon.dhcp.thefacebook.com>
2022-02-16 21:12       ` Matthew Wilcox
2022-02-16 21:44         ` Roman Gushchin
     [not found]           ` <Yg1y0ax5bnjGLAqz@casper.infradead.org>
     [not found]             ` <Yg16ClVQj8SLSlqV@carbon.DHCP.thefacebook.com>
2022-02-16 23:12               ` Matthew Wilcox
2022-02-16 23:57                 ` Shakeel Butt
2022-02-17  0:13                   ` Matthew Wilcox
2022-02-17  0:25                     ` Roman Gushchin
     [not found]                     ` <Yg2cKKnIboNu7j+p@carbon.DHCP.thefacebook.com>
     [not found]                       ` <11060a75-98c2-f547-68eb-fcab404a2539@virtuozzo.com>
2022-02-21  9:19                         ` Vlastimil Babka [this message]
2022-02-21 13:27                       ` Matthew Wilcox

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=00ca9ac6-0fd5-7cd1-7511-406eda292af3@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=linux-mm@kvack.org \
    --cc=shakeelb@google.com \
    --cc=vvs@virtuozzo.com \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).