Re: tools/cgroup/memcg_slabinfo.py is broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>

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.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux