On Tue, Sep 3, 2024 at 1:15 PM Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 2024/9/2 17:58, Ryan Roberts wrote:
> > Hi Baolin,
> >
> > Thanks for the review - I've been out on Paternity leave so only getting around
> > to replying now...
>
> No worries :)
>
> > On 09/08/2024 09:31, Baolin Wang wrote:
> >>
> >>
> >> On 2024/8/8 19:18, Ryan Roberts wrote:
> >>> Previously we had a situation where shmem mTHP controls and stats were
> >>> not exposed for some supported sizes and were exposed for some
> >>> unsupported sizes. So let's clean that up.
> >>>
> >>> Anon mTHP can support all large orders [2, PMD_ORDER]. But shmem can
> >>> support all large orders [1, MAX_PAGECACHE_ORDER]. However, per-size
> >>> shmem controls and stats were previously being exposed for all the anon
> >>> mTHP orders, meaning order-1 was not present, and for arm64 64K base
> >>> pages, orders 12 and 13 were exposed but were not supported internally.
> >>>
> >>> Tidy this all up by defining ctrl and stats attribute groups for anon
> >>> and file separately. Anon ctrl and stats groups are populated for all
> >>> orders in THP_ORDERS_ALL_ANON and file ctrl and stats groups are
> >>> populated for all orders in THP_ORDERS_ALL_FILE_DEFAULT.
> >>>
> >>> Additionally, create "any" ctrl and stats attribute groups which are
> >>> populated for all orders in (THP_ORDERS_ALL_ANON |
> >>> THP_ORDERS_ALL_FILE_DEFAULT). swpout stats use this since they apply to
> >>> anon and shmem.
> >>>
> >>> The side-effect of all this is that different hugepage-*kB directories
> >>> contain different sets of controls and stats, depending on which memory
> >>> types support that size. This approach is preferred over the
> >>> alternative, which is to populate dummy controls and stats for memory
> >>> types that do not support a given size.
> >>>
> >>> Signed-off-by: Ryan Roberts <ryan.roberts@xxxxxxx>
> >>> ---
> >>> mm/huge_memory.c | 144 +++++++++++++++++++++++++++++++++++++----------
> >>> 1 file changed, 114 insertions(+), 30 deletions(-)
> >>>
> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >>> index 0c3075ee00012..082d86b7c6c2f 100644
> >>> --- a/mm/huge_memory.c
> >>> +++ b/mm/huge_memory.c
> >>> @@ -482,8 +482,8 @@ static void thpsize_release(struct kobject *kobj);
> >>> static DEFINE_SPINLOCK(huge_anon_orders_lock);
> >>> static LIST_HEAD(thpsize_list);
> >>> -static ssize_t thpsize_enabled_show(struct kobject *kobj,
> >>> - struct kobj_attribute *attr, char *buf)
> >>> +static ssize_t anon_enabled_show(struct kobject *kobj,
> >>> + struct kobj_attribute *attr, char *buf)
> >>> {
> >>> int order = to_thpsize(kobj)->order;
> >>> const char *output;
> >>> @@ -500,9 +500,9 @@ static ssize_t thpsize_enabled_show(struct kobject *kobj,
> >>> return sysfs_emit(buf, "%s\n", output);
> >>> }
> >>> -static ssize_t thpsize_enabled_store(struct kobject *kobj,
> >>> - struct kobj_attribute *attr,
> >>> - const char *buf, size_t count)
> >>> +static ssize_t anon_enabled_store(struct kobject *kobj,
> >>> + struct kobj_attribute *attr,
> >>> + const char *buf, size_t count)
> >>> {
> >>> int order = to_thpsize(kobj)->order;
> >>> ssize_t ret = count;
> >>> @@ -544,19 +544,35 @@ static ssize_t thpsize_enabled_store(struct kobject *kobj,
> >>> return ret;
> >>> }
> >>> -static struct kobj_attribute thpsize_enabled_attr =
> >>> - __ATTR(enabled, 0644, thpsize_enabled_show, thpsize_enabled_store);
> >>> +static struct kobj_attribute anon_enabled_attr =
> >>> + __ATTR(enabled, 0644, anon_enabled_show, anon_enabled_store);
> >>> -static struct attribute *thpsize_attrs[] = {
> >>> - &thpsize_enabled_attr.attr,
> >>> +static struct attribute *anon_ctrl_attrs[] = {
> >>> + &anon_enabled_attr.attr,
> >>> + NULL,
> >>> +};
> >>> +
> >>> +static const struct attribute_group anon_ctrl_attr_grp = {
> >>> + .attrs = anon_ctrl_attrs,
> >>> +};
> >>> +
> >>> +static struct attribute *file_ctrl_attrs[] = {
> >>> #ifdef CONFIG_SHMEM
> >>> &thpsize_shmem_enabled_attr.attr,
> >>> #endif
> >>> NULL,
> >>> };
> >>> -static const struct attribute_group thpsize_attr_group = {
> >>> - .attrs = thpsize_attrs,
> >>> +static const struct attribute_group file_ctrl_attr_grp = {
> >>> + .attrs = file_ctrl_attrs,
> >>> +};
> >>> +
> >>> +static struct attribute *any_ctrl_attrs[] = {
> >>> + NULL,
> >>> +};
> >>> +
> >>> +static const struct attribute_group any_ctrl_attr_grp = {
> >>> + .attrs = any_ctrl_attrs,
> >>> };
> >>
> >> I wonder why adding a NULL group?
> >
> > It made everything a bit more generic and therefore extensible. Its my
> > preference to leave it as is, but will remove it if you insist.
>
> My preference is we should add it when necessary, but but I don't have a
> strong opinion. Let's see what other guys prefer, David, Barry?
I'm fine with either option. Adding a NULL control group makes it
easier for lazy
people like me to understand the current status, as it clearly
indicates that there
isn't a shared control group for file, shmem, and anon at the moment. :-)
Thanks
Barry
