Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2030156ybk; Mon, 11 May 2020 10:09:15 -0700 (PDT) X-Google-Smtp-Source: APiQypLw057qf4Bgx1v4AqnKFuvTLy4QPIvZKXM9WM33hCOHW8gKKDHSDB4nm6kPCouj8Tdqj2Ja X-Received: by 2002:a50:ec0c:: with SMTP id g12mr14866443edr.140.1589216955237; Mon, 11 May 2020 10:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589216955; cv=none; d=google.com; s=arc-20160816; b=jth7edSH4yR9symQIFM4Pzv37WLlV0bkeDP9svmNSqrqiSsxkm9rpDWZ9edNRVeEfU Nm8D8UdUPBxAWup7+pvudDL9+WiPc1UlSWT3liOwDxvp+ITmiAHSY1VXPl9YtfQKsTVv 4Zba4yyqq0wui56kHOhlnMnv+qWUx53AflEX24V4Ws3tfII5TTUXg3kQTQ7roP3AgAGm 0UOOZIr74iEi9L0l++lAi4MHGjKFhjRn813NT6pE2svaG3/3uyJjJL3AkaGtZKGy2QI6 U3U5zF4vu3RGoQpeVgnTk3PwqcTuTQdDUsKWwbWI2OrRMpN0dWnxfRSQ5kx/LY/R1bwr y4kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=bXc6/TC/fZd2A0tKIOuFHMPLNl2BdCBVGsE8fSj7QXY=; b=LYJVXuYKGrt+0n95yoUdK2J3rDwbLsSlClqf5dfTdWCEDvh/q86WKkjMOvzeNTPPNy 3MPSeu82AzSlrkwpidZRvl+rlCJ5Nt5ERH3Kc0rj4WBqguR65epCmhaxe7Eagnrk+SAB yt218WAjj8ubb5huK1VFB7YL1bvzrqe8Y+p+x4Mu/yfOTss+srEHuhOvPn9o7R2x22V4 eYnN6FUUkzbYAf9XXTVLk9wlNA6iFpbc/m3JnpRYTyEmmcO+6pEJq5z+Nw6F/IPkFtPu qusRrKYFLtmLSf3V2KuR4HatIYERNJ+VeiSRCMzjLH+gPBppvH7hpDkv4jGpLIXeQt7G GGOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=28Ffg6OR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m3si4157075ejr.464.2020.05.11.10.08.52; Mon, 11 May 2020 10:09:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=28Ffg6OR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730776AbgEKRHV (ORCPT + 99 others); Mon, 11 May 2020 13:07:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730734AbgEKRHU (ORCPT ); Mon, 11 May 2020 13:07:20 -0400 Received: from merlin.infradead.org (unknown [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92009C061A0C; Mon, 11 May 2020 10:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=bXc6/TC/fZd2A0tKIOuFHMPLNl2BdCBVGsE8fSj7QXY=; b=28Ffg6ORBIyHGTftSfOhouhHMk Tf6ecTJhdIajQ7tRRE5NmP+qKfDtEpdZqHsg1bIEjirRoF04iCG8I8WLGSm1Gw9pmxsrPQ2IdIFpY VKbR0W/fH6z41vCLkx8zhHyHRWCJOsavPXoNvuHkJnV4yc7HdLXSQ2ODzRIjk6cPZb4/BzPp9tNQs QWtW1PJTDA1PJFTLBCTPGXUkNSk8AxJtjyijDCBoKVBmyxwwmKP00bSlhHnUnSydU0IEKovGUGlvO zJ3qYS/6jVxeMgQas8m1UMDn8FODT5RlJejjWdTV4esB8mYPiId7Zv94MjBPSXjRltpaNDKSyMpyE 4YST0k2A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYBtB-00043D-UG; Mon, 11 May 2020 17:06:50 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id D0CA4301A66; Mon, 11 May 2020 19:06:46 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id BCF2B29DA4B49; Mon, 11 May 2020 19:06:46 +0200 (CEST) Date: Mon, 11 May 2020 19:06:46 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: Joerg Roedel , 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: <20200511170646.GJ2957@hirez.programming.kicks-ass.net> 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: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 08:36:31AM -0700, Andy Lutomirski wrote: > On Mon, May 11, 2020 at 12:42 AM Peter Zijlstra wrote: > > > > On Sat, May 09, 2020 at 12:05:29PM -0700, Andy Lutomirski wrote: > > > > > On x86_64, the only real advantage is that the handful of corner cases > > > that make vmalloc faults unpleasant (mostly relating to vmap stacks) > > > go away. On x86_32, a bunch of mind-bending stuff (everything your > > > series deletes but also almost everything your series *adds*) goes > > > away. There may be a genuine tiny performance hit on 2-level systems > > > due to the loss of huge pages in vmalloc space, but I'm not sure I > > > care or that we use them anyway on these systems. And PeterZ can stop > > > even thinking about RCU. > > > > > > Am I making sense? > > > > I think it'll work for x86_64 and that is really all I care about :-) > > Sadly, I think that Joerg has convinced my that this doesn't really > work for 32-bit unless we rework the LDT code or drop support for > something that we might not want to drop support for. I was thinking keep these patches for 32bit and fix 64bit 'proper'. But sure, if we can get rid of it all by stripping 32bit features I'm not going to object either.