On Sat, Nov 13, 2021 at 7:36 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote:
>
> Subject: Re: [PATCH v6] hugetlb: Add hugetlb.*.numa_stat file
>
> To: Muchun Song <songmuchun@xxxxxxxxxxxxx>, Mina Almasry <almasrymina@xxxxxxxxxx>
>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Shuah Khan <shuah@xxxxxxxxxx>, Miaohe Lin <linmiaohe@xxxxxxxxxx>, Oscar Salvador <osalvador@xxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, David Rientjes <rientjes@xxxxxxxxxx>, Shakeel Butt <shakeelb@xxxxxxxxxx>, Jue Wang <juew@xxxxxxxxxx>, Yang Yao <ygyao@xxxxxxxxxx>, Joanna Li <joannali@xxxxxxxxxx>, Cannon Matthews <cannonmatthews@xxxxxxxxxx>, Linux Memory Management List <linux-mm@xxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>
>
> Bcc:
>
> -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
>
> On 11/10/21 6:36 PM, Muchun Song wrote:
>
> > On Thu, Nov 11, 2021 at 9:50 AM Mina Almasry <almasrymina@xxxxxxxxxx> wrote:
>
> >>
>
> >> +struct hugetlb_cgroup_per_node {
>
> >> + /* hugetlb usage in pages over all hstates. */
>
> >> + atomic_long_t usage[HUGE_MAX_HSTATE];
>
> >
>
> > Why do you use atomic? IIUC, 'usage' is always
>
> > increased/decreased under hugetlb_lock except
>
> > hugetlb_cgroup_read_numa_stat() which is always
>
> > reading it. So I think WRITE_ONCE/READ_ONCE
>
> > is enough.
>
>
>
> Thanks for continuing to work this, I was traveling and unable to
>
> comment.
Have a good time.
>
>
>
> Unless I am missing something, I do not see a reason for WRITE_ONCE/READ_ONCE
Because __hugetlb_cgroup_commit_charge and
hugetlb_cgroup_read_numa_stat can run parallely,
which meets the definition of data race. I believe
KCSAN could report this race. I'm not strongly
suggest using WRITE/READ_ONCE() here. But
in theory it should be like this. Right?
Thanks.
>
> and would suggest going back to the way this code was in v5.
>
> --
>
> Mike Kravetz
>
