linux-kernel - Re: [PATCH] x86: enable RCU based table free when PARAVIRT

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170823195955.wnyg2dcv4c23kdoj@node.shutemov.name>
Date:   Wed, 23 Aug 2017 22:59:55 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jork Loeser <Jork.Loeser@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH] x86: enable RCU based table free when PARAVIRT

On Wed, Aug 23, 2017 at 11:26:46AM -0700, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
> >
> > Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> > is selected in config. Testing with kernbench doesn't show any notable
> > performance impact:
> 
> I wonder if we should just make it unconditional if it doesn't really
> show any performance difference. One less config complexity to worry
> about (and in this case I'm not so much worried about Kconfig itself,
> as just "oh, you have totally different paths in the core VM depending
> on PARAVIRT".

In this case we need performance numbers for !PARAVIRT kernel.

> That said, the thing to test for these kinds of things is often
> heavily scripted loads that just run thousands and thousands of really
> small processes, and build up and tear down page tables all the time
> because of fork/exit.
> 
> The load I've used occasionally is just "make test" in the git source
> tree. Tons and tons of trivial fork/exec/exit things for all those
> small tests and shell scripts.

Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
interesting too for worst case scenario.

-- 
 Kirill A. Shutemov