From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932679AbdHWT77 (ORCPT ); Wed, 23 Aug 2017 15:59:59 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35193 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932565AbdHWT76 (ORCPT ); Wed, 23 Aug 2017 15:59:58 -0400 Date: Wed, 23 Aug 2017 22:59:55 +0300 From: "Kirill A. Shutemov" To: Linus Torvalds Cc: Vitaly Kuznetsov , the arch/x86 maintainers , Linux Kernel Mailing List , xen-devel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "Kirill A. Shutemov" , Peter Zijlstra , Jork Loeser , KY Srinivasan , Stephen Hemminger , Steven Rostedt , Juergen Gross , Boris Ostrovsky , Andrew Cooper , Andy Lutomirski Subject: Re: [PATCH] x86: enable RCU based table free when PARAVIRT Message-ID: <20170823195955.wnyg2dcv4c23kdoj@node.shutemov.name> References: <20170823134521.5068-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 23, 2017 at 11:26:46AM -0700, Linus Torvalds wrote: > On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov 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