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=-2.2 required=3.0 tests=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 58198C54E8D for ; Mon, 11 May 2020 19:14:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 053C5206E6 for ; Mon, 11 May 2020 19:14:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 053C5206E6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6E4F890007B; Mon, 11 May 2020 15:14:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 694D7900036; Mon, 11 May 2020 15:14:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D07090007B; Mon, 11 May 2020 15:14:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 46931900036 for ; Mon, 11 May 2020 15:14:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0D02A499605 for ; Mon, 11 May 2020 19:14:21 +0000 (UTC) X-FDA: 76805389122.25.beast70_430aacc05cd58 X-HE-Tag: beast70_430aacc05cd58 X-Filterd-Recvd-Size: 3381 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 May 2020 19:14:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0909DAF6F; Mon, 11 May 2020 19:14:21 +0000 (UTC) Date: Mon, 11 May 2020 21:14:14 +0200 From: Joerg Roedel To: Andy Lutomirski Cc: Peter Zijlstra , Joerg Roedel , X86 ML , "H. Peter Anvin" , Dave Hansen , "Rafael J. Wysocki" , Arnd Bergmann , Andrew Morton , Steven Rostedt , Vlastimil Babka , Michal Hocko , LKML , Linux ACPI , linux-arch , Linux-MM Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Message-ID: <20200511191414.GY8135@suse.de> References: <20200508144043.13893-1-joro@8bytes.org> <20200508213609.GU8135@suse.de> <20200509175217.GV8135@suse.de> <20200511074243.GE2957@hirez.programming.kicks-ass.net> 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) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 11, 2020 at 08:36:31AM -0700, Andy Lutomirski wrote: > What if we make 32-bit PTI depend on PAE? It already does, PTI support for legacy paging had to be removed because there were memory corruption problems with THP. The reason was that huge PTEs in the user-space area were mapped in two page-tables (kernel and user), but A/D bits were only fetched from the kernel part. To not make things more complicated we agreed on just not supporting PTI without PAE. > And drop 32-bit Xen PV support? And make 32-bit huge pages depend on > PAE? Then 32-bit non-PAE can use the direct-mapped LDT, 32-bit PTI > (and optionally PAE non-PTI) can use the evil virtually mapped LDT. > And 32-bit non-PAE (the 2-level case) will only have pointers to page > tables at the top level. And then we can preallocate. Not sure I can follow you here. How can 32-bit PTI with PAE use the LDT from the direct mapping? I am guessing you want to get rid of the SHARED_KERNEL_PMD==0 case for PAE kernels. This would indeed make syncing unneccessary on PAE, but pre-allocation would still be needed for 2-level paging. Just the amount of memory needed for the pre-allocated PTE pages is half as big as it would be with PAE. > Or maybe we don't want to defeature this much, or maybe the memory hit > from this preallocation will hurt little 2-level 32-bit systems too > much. It will certainly make Linux less likely to boot on low-memory x86-32 systems, whoever will be affected by this. Joerg