From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E31FC433DF for ; Tue, 13 Oct 2020 08:06:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BB1BE2074A for ; Tue, 13 Oct 2020 08:06:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391059AbgJMIGw (ORCPT ); Tue, 13 Oct 2020 04:06:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:37856 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389340AbgJMIGB (ORCPT ); Tue, 13 Oct 2020 04:06:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 85A1CAD6B; Tue, 13 Oct 2020 08:05:59 +0000 (UTC) Date: Tue, 13 Oct 2020 10:05:57 +0200 From: Joerg Roedel To: Linus Torvalds Cc: Ingo Molnar , Linux Kernel Mailing List , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , Andrew Morton Subject: Re: [GIT PULL] x86/mm changes for v5.10 Message-ID: <20201013080557.GF3302@suse.de> References: <20201012172415.GA2962950@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12, 2020 at 03:07:45PM -0700, Linus Torvalds wrote: > On Mon, Oct 12, 2020 at 10:24 AM Ingo Molnar wrote: > > > > Do not sync vmalloc/ioremap mappings on x86-64 kernels. > > > > Hopefully now without the bugs! > > Let's hope so. > > If this turns out to work this time, can we do a similar preallocation > of the page directories on 32-bit? Because I think now x86-32 is the > only remaining case of doing that arch_sync_kernel_mappings() thing. > > Or is there some reason that won't work that I've lost sight of? There were two reasons which made me decide to not pre-allocate on x86-32: 1) The sync-level is the same as the huge-page level (PMD) on both paging modes, so with large ioremap mappings the synchronization is always needed. The huge ioremap mapping could possibly be disabled without much performance impact on x86-32. 2) The vmalloc area has a variable size and grows with less RAM in the machine. And when the vmalloc area gets larger, more pages are needed. Another factor is the configurable vm-split. With a 1G/3G split on a machine with 128MB of RAM there would be: VMalloc area size (hole ignored): 3072MB - 128MB = 2944MB PTE-pages needed (with PAE): 2944MB / 2MB/page = 1472 4k pages Memory needed: 1472*4k = 5888kb So on such machine the pre-allocation would need 5.75MB of the 128MB RAM. Without PAE it is half of that. This is an exotic configuration and I am not sure it matters much in practice. It could also be worked around by setting limits such as, for example, don't make the vmalloc area larger then the avauilable memory in the system. So pre-allocating has its implications. If we decide to pre-allocate on x86-32 too, then we should be prepared for that fall-out of the higher memory usage. Regards, Joerg