From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Date: Fri, 8 May 2020 23:34:07 +0200 Message-ID: <20200508213407.GT8135@suse.de> References: <20200508144043.13893-1-joro@8bytes.org> <20200508192000.GB2957@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200508192000.GB2957@hirez.programming.kicks-ass.net> Sender: linux-acpi-owner@vger.kernel.org To: Peter Zijlstra Cc: Joerg Roedel , x86@kernel.org, hpa@zytor.com, Dave Hansen , Andy Lutomirski , rjw@rjwysocki.net, Arnd Bergmann , Andrew Morton , Steven Rostedt , Vlastimil Babka , Michal Hocko , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org List-Id: linux-arch.vger.kernel.org Hi Peter, thanks for reviewing this! On Fri, May 08, 2020 at 09:20:00PM +0200, Peter Zijlstra wrote: > The only concern I have is the pgd_lock lock hold times. > > By not doing on-demand faults anymore, and consistently calling > sync_global_*(), we iterate that pgd_list thing much more often than > before if I'm not mistaken. Should not be a problem, from what I have seen this function is not called often on x86-64. The vmalloc area needs to be synchronized at the top-level there, which is by now P4D (with 4-level paging). And the vmalloc area takes 64 entries, when all of them are populated the function will not be called again. On 32bit it might be called more often, because synchronization happens on the PMD level, which is also used for large-page mapped ioremap regions. But these don't happen very often and there are also no VMAP stacks on x86-32 which could cause this function to be called frequently. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:36542 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726811AbgEHVeK (ORCPT ); Fri, 8 May 2020 17:34:10 -0400 Date: Fri, 8 May 2020 23:34:07 +0200 From: Joerg Roedel Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Message-ID: <20200508213407.GT8135@suse.de> References: <20200508144043.13893-1-joro@8bytes.org> <20200508192000.GB2957@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200508192000.GB2957@hirez.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Joerg Roedel , x86@kernel.org, hpa@zytor.com, Dave Hansen , Andy Lutomirski , rjw@rjwysocki.net, Arnd Bergmann , Andrew Morton , Steven Rostedt , Vlastimil Babka , Michal Hocko , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Message-ID: <20200508213407.sdK3r7LBm1i50-fasH_0WnQ2jBQP5tKtkb_UjMBJ6yQ@z> Hi Peter, thanks for reviewing this! On Fri, May 08, 2020 at 09:20:00PM +0200, Peter Zijlstra wrote: > The only concern I have is the pgd_lock lock hold times. > > By not doing on-demand faults anymore, and consistently calling > sync_global_*(), we iterate that pgd_list thing much more often than > before if I'm not mistaken. Should not be a problem, from what I have seen this function is not called often on x86-64. The vmalloc area needs to be synchronized at the top-level there, which is by now P4D (with 4-level paging). And the vmalloc area takes 64 entries, when all of them are populated the function will not be called again. On 32bit it might be called more often, because synchronization happens on the PMD level, which is also used for large-page mapped ioremap regions. But these don't happen very often and there are also no VMAP stacks on x86-32 which could cause this function to be called frequently. Joerg