linux-kernel - Re: [RFC v1 00/19] Modify zonelist to nodelist v1

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]

Date:   Mon, 25 Nov 2019 16:46:51 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Pengfei Li <fly@...nel.page>
Cc:     akpm@...ux-foundation.org, mgorman@...hsingularity.net,
        vbabka@...e.cz, cl@...ux.com, iamjoonsoo.kim@....com, guro@...com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC v1 00/19] Modify zonelist to nodelist v1

On Mon 25-11-19 22:46:03, Pengfei Li wrote:
> On Mon, 25 Nov 2019 09:40:58 +0100
> Michal Hocko <mhocko@...nel.org> wrote:
> 
> > On Fri 22-11-19 23:05:43, Pengfei Li wrote:
> > > On Thu, 21 Nov 2019 19:04:01 +0100
> > > Michal Hocko <mhocko@...nel.org> wrote:
> > > 
> > > > On Thu 21-11-19 23:17:52, Pengfei Li wrote:
> > > > [...]
> > > > > Since I don't currently have multiple node NUMA systems, I
> > > > > would be grateful if anyone would like to test this series of
> > > > > patches.
> > > > 
> > > > I didn't really get to think about the actual patchset. From a
> > > > very quick glance I am wondering whether we need to optimize as
> > > > there are usually only small amount of numa nodes. But I am quite
> > > > busy so I cannot really do any claims.
> > > 
> > > Thanks for your comments.
> > > 
> > > I think it's time to modify the zonelist to nodelist because the
> > > zonelist is always in node order and the page reclamation is based
> > > on node.
> > > 
> > > I will do more performance testing to show that multi-node systems
> > > will benefit from this series of patches.
> > 
> > Sensible performance numbers on multiple workloads (ideally some real
> > world ones rather than artificial microbenchmarks) is essential for a
> > performance optimization that is this large.
> 
> 
> Thank you for your suggestion.
> 
> But this is probably a bit difficult because I don't have a NUMA server
> to do real-world workload testing.

For this particular feature you really do not need any real NUMA server.
Your patch shouldn't introduce NUMA locality. All you are aiming for is
to optimize the zone list iteration.

> I will do as many performance benchmarks as possible, just like Mel
> Gorman's "Move LRU page reclaim from zones to nodes v9"
> (https://lwn.net/Articles/694121/).

Be aware that this will be quite time consuming and non-trivial to
process/evaluate. Not that I want to discourage you from this endeavor
but it is always good to think whether your final goal really has a
potential to a visible optimization. I might be wrong but only the page
allocator should really be the hot path which iterates over zonelist
so a microbenchmark targeting this path would be something I would start
with. Unless there are some really nice results from there I would lose
more time with other benchmarks.
-- 
Michal Hocko
SUSE Labs