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: <CAMgjq7CebYhwgUzBV9tGENEfVMxPMS4qVXvRx=sVQOEAUbq_mA@mail.gmail.com>
Date:   Fri, 12 Aug 2022 12:49:29 +0800
From:   Kairui Song <ryncsn@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH] mm/util: reduce stack usage of folio_mapcount

Andrew Morton <akpm@...ux-foundation.org> 于2022年8月12日周五 07:07写道:
>
> On Tue,  2 Aug 2022 01:31:55 +0800 Kairui Song <ryncsn@...il.com> wrote:
>
> > From: Kairui Song <kasong@...cent.com>
> >
> > folio_entire_mapcount will call PageHeadHuge which is a function call,
> > and blocks the compiler from recognizing this redundant load.
>
> Did you mean folio_test_hugetlb() rather than folio_entire_mapcount()?

Thanks for checking out this patch, and Yes, it's folio_test_hugetlb,
my mistake...

>
>
> > After rearranging the code, stack usage is dropped from 32 to 24, and
> > the function size is smaller (tested on GCC 12):
> >
> > Before:
> > Stack usage:
> > mm/util.c:845:5:folio_mapcount  32      static
> > Size:
> > 0000000000000ea0 00000000000000c7 T folio_mapcount
> >
> > After:
> > Stack usage:
> > mm/util.c:845:5:folio_mapcount  24      static
> > Size:
> > 0000000000000ea0 00000000000000b0 T folio_mapcount
> >
> > ...
> >
> > @@ -850,10 +850,10 @@ int folio_mapcount(struct folio *folio)
> >               return atomic_read(&folio->_mapcount) + 1;
> >
> >       compound = folio_entire_mapcount(folio);
> > -     nr = folio_nr_pages(folio);
> >       if (folio_test_hugetlb(folio))
> >               return compound;
> >       ret = compound;
> > +     nr = folio_nr_pages(folio);
> >       for (i = 0; i < nr; i++)
> >               ret += atomic_read(&folio_page(folio, i)->_mapcount) + 1;
> >       /* File pages has compound_mapcount included in _mapcount */
> > --
> > 2.35.2

Is the rest of the patch a valid fix? Should I send V2?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ