From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752192AbdI2OCd (ORCPT ); Fri, 29 Sep 2017 10:02:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24726 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbdI2OCc (ORCPT ); Fri, 29 Sep 2017 10:02:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DEB82356D4 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=vkuznets@redhat.com From: Vitaly Kuznetsov To: Peter Zijlstra Cc: kernel test robot , Ingo Molnar , Juergen Gross , "Kirill A. Shutemov" , Andrew Cooper , Andy Lutomirski , Boris Ostrovsky , Jork Loeser , KY Srinivasan , Linus Torvalds , "Paul E. McKenney" , Stephen Hemminger , Steven Rostedt , Thomas Gleixner , LKML , lkp@01.org Subject: Re: [lkp-robot] [x86/mm] 9e52fc2b50: will-it-scale.per_thread_ops -16% regression References: <20170927055914.GO17200@yexl-desktop> <87d169zo9o.fsf@vitty.brq.redhat.com> <20170929131329.tekd6a7yfrkm7lwl@hirez.programming.kicks-ass.net> <20170929131609.i5t46af7nkjwekbk@hirez.programming.kicks-ass.net> Date: Fri, 29 Sep 2017 16:02:27 +0200 In-Reply-To: <20170929131609.i5t46af7nkjwekbk@hirez.programming.kicks-ass.net> (Peter Zijlstra's message of "Fri, 29 Sep 2017 15:16:09 +0200") Message-ID: <874lrlzjpo.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 29 Sep 2017 14:02:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Fri, Sep 29, 2017 at 03:13:29PM +0200, Peter Zijlstra wrote: >> On Fri, Sep 29, 2017 at 02:24:03PM +0200, Vitaly Kuznetsov wrote: >> > 1) In case the system is under extreme memory pressure and >> > __get_free_page() is failing in tlb_remove_table() we'll be doing >> > smp_call_function() for _each_ call (avoiding batching). We may want to >> > have a pre-allocated pool. >> >> MMU_GATHER_BUNDLE should avoid it being for _every_ call. > > My bad, that's only for pages, not tables :/ > >> Also, note that tlb_gather is preemptible, so pre-alloc is 'difficult' >> and you will run out, esp. when memory is right. >> (purely teoretical thought) what I meant to say is in tlb_remove_table() we may try to get new batch from some pre-allocated (on boot) pool and revert to __get_free_page() when it's empty. This may make sense combined with the next idea, allocating more than 1 page. >> > 2) The default MAX_TABLE_BATCH is static (it is equal to the number of >> > pointer we can fit into one page - sizeof(struct mmu_table_batch) == >> > 509), we may want to adjust it for very big systems. >> >> That would then put more stress on the memory allocator because you're >> then asking for higher order pages. Of course, but the question is: what's cheaper -- try to alloc e.g. 8 pages or do 8 smp_call_function() calls? But adding such complexity to the code would require a good justification, of course. -- Vitaly