lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201203034917.GA1571588@carbon.DHCP.thefacebook.com>
Date:   Wed, 2 Dec 2020 19:49:17 -0800
From:   Roman Gushchin <guro@...com>
To:     Muchun Song <songmuchun@...edance.com>
CC:     Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Cgroups <cgroups@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH] mm/memcontrol: make the slab calculation
 consistent

On Thu, Dec 03, 2020 at 11:36:54AM +0800, Muchun Song wrote:
> On Thu, Dec 3, 2020 at 11:21 AM Roman Gushchin <guro@...com> wrote:
> >
> > On Thu, Dec 03, 2020 at 10:53:33AM +0800, Muchun Song wrote:
> > > On Thu, Dec 3, 2020 at 5:16 AM Roman Gushchin <guro@...com> wrote:
> > > >
> > > > On Wed, Dec 02, 2020 at 08:14:34PM +0800, Muchun Song wrote:
> > > > > Although the ratio of the slab is one, we also should read the ratio
> > > > > from the related memory_stats instead of hard-coding. And the local
> > > > > variable of size is already the value of slab_unreclaimable. So we
> > > > > do not need to read again. Simplify the code here.
> > > > >
> > > > > Signed-off-by: Muchun Song <songmuchun@...edance.com>
> > > > > ---
> > > > >  mm/memcontrol.c | 22 +++++++++++++++++-----
> > > > >  1 file changed, 17 insertions(+), 5 deletions(-)
> > > >
> > > > Hi Muchun!
> > > >
> > > > >
> > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > > index 9922f1510956..03a9c64560f6 100644
> > > > > --- a/mm/memcontrol.c
> > > > > +++ b/mm/memcontrol.c
> > > > > @@ -1545,12 +1545,22 @@ static int __init memory_stats_init(void)
> > > > >       int i;
> > > > >
> > > > >       for (i = 0; i < ARRAY_SIZE(memory_stats); i++) {
> > > > > +             switch (memory_stats[i].idx) {
> > > > >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > > > -             if (memory_stats[i].idx == NR_ANON_THPS ||
> > > > > -                 memory_stats[i].idx == NR_FILE_THPS ||
> > > > > -                 memory_stats[i].idx == NR_SHMEM_THPS)
> > > > > +             case NR_ANON_THPS:
> > > > > +             case NR_FILE_THPS:
> > > > > +             case NR_SHMEM_THPS:
> > > > >                       memory_stats[i].ratio = HPAGE_PMD_SIZE;
> > > > > +                     break;
> > > > >  #endif
> > > > > +             case NR_SLAB_UNRECLAIMABLE_B:
> > > > > +                     VM_BUG_ON(i < 1);
> > > > > +                     VM_BUG_ON(memory_stats[i - 1].idx != NR_SLAB_RECLAIMABLE_B);
> > > >
> > > > Please, convert these to BUILD_BUG_ON(), they don't have to be runtime checks.
> > >
> > > Agree. But here we cannot use BUILD_BUG_ON(). The compiler will
> > > complain about it.
> >
> > We can!
> >
> > We just need to change the condition. All we really need to check is that
> > NR_SLAB_UNRECLAIMABLE_B immediately following NR_SLAB_RECLAIMABLE_B.
> 
> But I think that we need to check that memory_stats[i] immediately following
> memory_stats[j] where i is the index of NR_SLAB_UNRECLAIMABLE_B and
> j is the index of NR_SLAB_RECLAIMABLE_B.

Ok, I see. Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ