Received-SPF: pass (google.com: domain of linux-kernel+bounces-87666-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Hao Ge <gehao618@163.com>
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2] mm/vmstat: Add order's information for extfrag_index and unusable_index
Date: Fri, 1 Mar 2024 07:13:51 +0800
Message-Id: <F38EE8B9-3C29-43DC-A471-3DF6242B9804@163.com>
References: <20240229104013.5ed8c1ca9c2dbd0bd5fb571f@linux-foundation.org>
Cc: Hao Ge <gehao@kylinos.cn>, linux-mm@kvack.org,
 linux-kernel@vger.kernel.org
In-Reply-To: <20240229104013.5ed8c1ca9c2dbd0bd5fb571f@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>


> On Mar 1, 2024, at 02:40, Andrew Morton <akpm@linux-foundation.org> wrote:=

>=20
> =EF=BB=BFOn Thu, 29 Feb 2024 22:14:43 +0800 Hao Ge <gehao@kylinos.cn> wrot=
e:
>=20
>> Current cat /sys/kernel/debug/extfrag/extfrag_index and
>> /sys/kernel/debug/extfrag/unusable_index is not friendly to userspace.
>>=20
>> We should add order's information so that users can clearly understand
>> the situation of each order at a glance like pagetypeinfo.
>>=20
>> before:
>> cat /sys/kernel/debug/extfrag/extfrag_index:
>> Node 0, zone    DMA32  ...... ...... ...... ......
>> Node 0, zone   Normal  ...... ...... ...... ......
>>=20
>> cat /sys/kernel/debug/extfrag/unusable_index:
>> Node 0, zone    DMA32 ..... ..... ..... .....
>> Node 0, zone   Normal ..... ..... ..... .....
>>=20
>> after:
>> cat /sys/kernel/debug/extfrag/extfrag_index:
>> Extfrag index at order:       0      1      2      3
>> Node 0, zone        DMA  ...... ...... ...... ......
>> Node 0, zone     Normal  ...... ...... ...... ......
>>=20
>> cat /sys/kernel/debug/extfrag/unusable_index:
>> Unusable index at order:     0     1     2     3
>> Node 0, zone         DMA ..... ..... ..... .....
>> Node 0, zone      Normal ..... ..... ..... .....
>>=20
>=20
> This may break existing parsers of this file.
>=20
> And that would be allowed if these files were under debugfs.  But
> they're under sysfs/debug, where the rules are less clear.
>=20
> Still, it's unclear to me that the benefit is worth this risk.  What do
> others think?

Thank you for your reply. This is something I didn't expect. I think it's be=
tter to keep it in its original condition to avoid compatibility issues with=
 some tools.=