Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp556734ybk; Sat, 9 May 2020 10:56:53 -0700 (PDT) X-Google-Smtp-Source: APiQypI6nG7zUsPYBvR2mw0OWgyqRxFVisb2E9z88Ks9ZzLZEOp5eLgUiO8wfZCOOS9IQElFGI8Y X-Received: by 2002:a17:906:6b05:: with SMTP id q5mr6866260ejr.329.1589047013513; Sat, 09 May 2020 10:56:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589047013; cv=none; d=google.com; s=arc-20160816; b=iD6AdwL/lgrKhw08i9wE/mZjc4FeuANA2D2dgcEqYX7GFkYUoQVgRqkPd6uNfYzU1y j3JWbGu1qsDnDpZSoqgkUOr3hyMqfbk6Vp97IIO4vp60c/E1vXMLXDe+U/rNaeW8BkUk g+8figZqV65SYLU2MQ49dcrbA3NgtpLrxz9bT6Ar+UKckjJfsx4p5iRqUnxadgLiUVHv uN+890i60px30Jx3VhP2tjiv+ON9kA7Au0G0HtvXuwJZSp23obkXdjmThqc9KpGe8hjv KVLcKzi/Px71bqVj392MRgCwYKSeTEci5N2Eqr4vxQrf98ZUQdeE2KxERYa/vR3r9EI2 qTAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=npBaOj1QJT6sizWI4ER+rb1pCAL1l+lh31mCarcHOg4=; b=GFTw+IGSuulrajX+EbsSzw/4PjCYPEoAgh7muhysvxI6B5IpLm1gTuCsGcdUR1TL84 ueAenE3OVM7t/GLnR784pWH393ShZ2p70gVu+tqtIl5DYLLiJy2mtIWJagzpLBuF80ye w39MdnwkKhZ6YfBFvLo9uwUoKEyJfNVcx6fk9bhmhKrEjkKWnSpnPmh4vHwOG3kWOc1Q yPypK2iYdCXSST8xEuraB67sgS6WB02FTHnIWV1nxhCTdC14DeddjWo7/VdSeRNiT/QM DFwwYS0j2RGVwaOhQasQpVb6wjCXQsgx9PJ7zxXyWrLszF4X8wpSuzXeYPgBzRddERjo /44g== ARC-Authentication-Results: i=1; mx.google.com; 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 j4si3252237edq.8.2020.05.09.10.56.29; Sat, 09 May 2020 10:56:53 -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; 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 S1728552AbgEIRyw (ORCPT + 99 others); Sat, 9 May 2020 13:54:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:55210 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726214AbgEIRyv (ORCPT ); Sat, 9 May 2020 13:54:51 -0400 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 D8F4DAC26; Sat, 9 May 2020 17:54:52 +0000 (UTC) Date: Sat, 9 May 2020 19:54:48 +0200 From: Joerg Roedel 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 Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Message-ID: <20200509175448.GW8135@suse.de> References: <20200508144043.13893-1-joro@8bytes.org> <20200508192000.GB2957@hirez.programming.kicks-ass.net> <20200508213407.GT8135@suse.de> <20200509092516.GC2957@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200509092516.GC2957@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 09, 2020 at 11:25:16AM +0200, Peter Zijlstra wrote: > Right; it's just that the moment you do trigger it, it'll iterate that > pgd_list and that is potentially huge. Then again, that's not a new > problem. > > I suppose we can deal with it if/when it becomes an actual problem. > > I had a quick look and I think it might be possible to make it an RCU > managed list. We'd have to remove the pgd_list entry in > put_task_struct_rcu_user(). Then we can play games in sync_global_*() > and use RCU iteration. New tasks (which can be missed in the RCU > iteration) will already have a full clone of the PGD anyway. Right, it should not be that difficult to rcu-protect the pgd-list, but we can try that when it actually becomes a problem. Joerg