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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 3778BC47247 for ; Fri, 8 May 2020 23:49:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1775524953 for ; Fri, 8 May 2020 23:49:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588981774; bh=mIKkm78zlsFmzyNyUggpg/nLJ1Pv+yfyI9aRpBMvboY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=mmwScKRTAddNWF9oZQhNRyIM0KZ4+rLKcmEPGHB1dFEn1BsiatsRRkFtNONx9wqTU QZePHi3Qgn0e5EJm7LwnmfIm+yXDYR+BO/z134ARyohP4xSapzmsCDzKJf31LU4Rxy yrFgoVJTnQrtoUsdXRtW47hxTXf1Ar8+bqz/lH5I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728051AbgEHXtd (ORCPT ); Fri, 8 May 2020 19:49:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:50432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727774AbgEHXtb (ORCPT ); Fri, 8 May 2020 19:49:31 -0400 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1344A24965 for ; Fri, 8 May 2020 23:49:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588981771; bh=mIKkm78zlsFmzyNyUggpg/nLJ1Pv+yfyI9aRpBMvboY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Qgrr/ZVrtyMMSjMvGdjIv+FxJZuAng9m7yuTdoCTyOB79iIyIxJif4vCLsbkFNCoK qXIxL+QBwozjrrBbZe3ADXJGrf4sPvGFA4/sHOtcGrKlf1HKamC+RT5s3LctwL8pAQ ysSq0F9r3y6BM21/Dmx5hSBkWO5ZF2Tjj3znNxI0= Received: by mail-wm1-f48.google.com with SMTP id e26so11951955wmk.5 for ; Fri, 08 May 2020 16:49:30 -0700 (PDT) X-Gm-Message-State: AGi0PuaOcK7eqShrwC5kDdgOA3mYMSooVeRDqRPLAu30CULiX6Q3F+YO K2YKp1tEJMUeS0skshl+x2QnWcUzUouAi2h5pK4tww== X-Google-Smtp-Source: APiQypK0d4AuGP8O5iSc/+LZKwChQkendzKhSNJ9rrZnhtoC2RLyao6v06bE42N0zruNedhXQebsB28r6/WvMhKE28c= X-Received: by 2002:a1c:9989:: with SMTP id b131mr18252758wme.176.1588981769476; Fri, 08 May 2020 16:49:29 -0700 (PDT) MIME-Version: 1.0 References: <20200508144043.13893-1-joro@8bytes.org> <20200508213609.GU8135@suse.de> In-Reply-To: <20200508213609.GU8135@suse.de> From: Andy Lutomirski Date: Fri, 8 May 2020 16:49:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() To: Joerg Roedel Cc: Andy Lutomirski , Joerg Roedel , X86 ML , "H. Peter Anvin" , Dave Hansen , Peter Zijlstra , "Rafael J. Wysocki" , Arnd Bergmann , Andrew Morton , Steven Rostedt , Vlastimil Babka , Michal Hocko , LKML , Linux ACPI , linux-arch , Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, May 8, 2020 at 2:36 PM Joerg Roedel wrote: > > On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote: > > On Fri, May 8, 2020 at 7:40 AM Joerg Roedel wrote: > > > What's the maximum on other system types? It might make more sense to > > take the memory hit and pre-populate all the tables at boot so we > > never have to sync them. > > Need to look it up for 5-level paging, with 4-level paging its 64 pages > to pre-populate the vmalloc area. > > But that would not solve the problem on x86-32, which needs to > synchronize unmappings on the PMD level. What changes in this series with x86-32? We already do that synchronization, right? IOW, in the cases where the vmalloc *fault* code does anything at all, we should have a small bound for how much memory to preallocate and, if we preallocate it, then there is nothing to sync and nothing to fault. And we have the benefit that we never need to sync anything on 64-bit, which is kind of nice. Do we actually need PMD-level things for 32-bit? What if we just outlawed huge pages in the vmalloc space on 32-bit non-PAE? Or maybe the net result isn't much of a cleanup after all given the need to support 32-bit. > > > Joerg 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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 28B4DC38A2A for ; Fri, 8 May 2020 23:49:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A76C52063A for ; Fri, 8 May 2020 23:49:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qgrr/ZVr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A76C52063A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1F4B1900024; Fri, 8 May 2020 19:49:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1801690001C; Fri, 8 May 2020 19:49:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06E6E900024; Fri, 8 May 2020 19:49:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id E41BD90001C for ; Fri, 8 May 2020 19:49:32 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9A287181AEF07 for ; Fri, 8 May 2020 23:49:32 +0000 (UTC) X-FDA: 76795196184.14.end19_70612d3f53b05 X-HE-Tag: end19_70612d3f53b05 X-Filterd-Recvd-Size: 3903 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 May 2020 23:49:32 +0000 (UTC) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 19CFE2496B for ; Fri, 8 May 2020 23:49:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588981771; bh=mIKkm78zlsFmzyNyUggpg/nLJ1Pv+yfyI9aRpBMvboY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Qgrr/ZVrtyMMSjMvGdjIv+FxJZuAng9m7yuTdoCTyOB79iIyIxJif4vCLsbkFNCoK qXIxL+QBwozjrrBbZe3ADXJGrf4sPvGFA4/sHOtcGrKlf1HKamC+RT5s3LctwL8pAQ ysSq0F9r3y6BM21/Dmx5hSBkWO5ZF2Tjj3znNxI0= Received: by mail-wm1-f50.google.com with SMTP id r26so12544040wmh.0 for ; Fri, 08 May 2020 16:49:31 -0700 (PDT) X-Gm-Message-State: AGi0PuYLM/V/GpxBy/PAglIVGF6xyEpk6Tz+NxCdX2UnlAVW/QzXCY0B saYSpPXgXqf55sahanz8NU83/JaKFm0HNJHiTl7Eng== X-Google-Smtp-Source: APiQypK0d4AuGP8O5iSc/+LZKwChQkendzKhSNJ9rrZnhtoC2RLyao6v06bE42N0zruNedhXQebsB28r6/WvMhKE28c= X-Received: by 2002:a1c:9989:: with SMTP id b131mr18252758wme.176.1588981769476; Fri, 08 May 2020 16:49:29 -0700 (PDT) MIME-Version: 1.0 References: <20200508144043.13893-1-joro@8bytes.org> <20200508213609.GU8135@suse.de> In-Reply-To: <20200508213609.GU8135@suse.de> From: Andy Lutomirski Date: Fri, 8 May 2020 16:49:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() To: Joerg Roedel Cc: Andy Lutomirski , Joerg Roedel , X86 ML , "H. Peter Anvin" , Dave Hansen , Peter Zijlstra , "Rafael J. Wysocki" , Arnd Bergmann , Andrew Morton , Steven Rostedt , Vlastimil Babka , Michal Hocko , LKML , Linux ACPI , linux-arch , Linux-MM Content-Type: text/plain; charset="UTF-8" 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 Fri, May 8, 2020 at 2:36 PM Joerg Roedel wrote: > > On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote: > > On Fri, May 8, 2020 at 7:40 AM Joerg Roedel wrote: > > > What's the maximum on other system types? It might make more sense to > > take the memory hit and pre-populate all the tables at boot so we > > never have to sync them. > > Need to look it up for 5-level paging, with 4-level paging its 64 pages > to pre-populate the vmalloc area. > > But that would not solve the problem on x86-32, which needs to > synchronize unmappings on the PMD level. What changes in this series with x86-32? We already do that synchronization, right? IOW, in the cases where the vmalloc *fault* code does anything at all, we should have a small bound for how much memory to preallocate and, if we preallocate it, then there is nothing to sync and nothing to fault. And we have the benefit that we never need to sync anything on 64-bit, which is kind of nice. Do we actually need PMD-level things for 32-bit? What if we just outlawed huge pages in the vmalloc space on 32-bit non-PAE? Or maybe the net result isn't much of a cleanup after all given the need to support 32-bit. > > > Joerg