[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1801415b.a202.1936d01f953.Coremail.00107082@163.com>
Date: Wed, 27 Nov 2024 17:44:26 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Suren Baghdasaryan" <surenb@...gle.com>
Cc: kent.overstreet@...ux.dev, linux-kernel@...r.kernel.org, yuzhao@...gle.com
Subject: Re: Abnormal values show up in /proc/allocinfo
At 2024-11-27 01:10:23, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
>
>Hi David,
>Thanks for the investigation. I think your suggestion should work fine
>and it's simpler than what we do now. It will swap not only counters
>but allocation locations as well, however I think we already do that
>when we call __alloc_tag_ref_set(). So, instead of clearing the
>original tag, decrementing the new tag's counter (to compensate for
>its own allocation) and reassigning the old tag to the new counter,
>you simply swap the tags. That seems fine to me.
>However I think there is still a bug where some get_new_folio()
>callback does not increment the new folio's counters and that's why we
>get an underflow when calling alloc_tag_sub(). I'll try to reproduce
>on my side and see what's going on there.
Agreed, the reason for underflow with current code should be clarified.
Just update reproduce procedure:
1. fio --randrepeat=1 --ioengine=libaio --direct=1 --name=test --bs=4k --iodepth=64 --size=1G --readwrite=randrw --runtime=100 --numjobs=4 --time_based=1
2. echo 1 >/proc/sys/vm/compact_memory
3. echo 1 > /proc/sys/vm/drop_caches
(It is very strange, on my VM, "echo 3 > /proc/sys/vm/drop_caches" would not trigger easily.
4 cat /proc/allocinfo | grep __filemap_get_folio
FYI
David
>Thanks,
>Suren.
>
>>
>> static void shutdown_mem_profiling(bool remove_file)
>>
>>
>>
>> FYI
>> David
>>
>>
>> >
>> >Thanks~
>> >David
>> >
>> >>
>> >>> > >Thanks,
>> >>> > >Suren.
>> >>> > >
>> >>> > >>
>> >>> > >>
>> >>> > >> Thanks
>> >>> > >> David
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
Powered by blists - more mailing lists