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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 258B8C433F5 for ; Wed, 4 May 2022 08:20:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC49B6B0096; Wed, 4 May 2022 04:20:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B73D26B0098; Wed, 4 May 2022 04:20:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A63606B0099; Wed, 4 May 2022 04:20:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9824D6B0096 for ; Wed, 4 May 2022 04:20:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 70EC220DC2 for ; Wed, 4 May 2022 08:20:52 +0000 (UTC) X-FDA: 79427364744.04.2A0AE46 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 602AE140076 for ; Wed, 4 May 2022 08:20:46 +0000 (UTC) Received: by mail-vk1-f171.google.com with SMTP id n135so265866vkn.7 for ; Wed, 04 May 2022 01:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TZeM2sK6VsFpvnvIUwVCoNa4r1ezlmI7cS8ZgepmC84=; b=hSNZbMrTMFievu5D9MtMUJMwIDI8+/jQVZxuuo+3f9e8nR41TGIc9FzDpRb0hjzBGP j/wAcoRO8SZrWabKfZaBkxYlA+SBRBfWlcNA/+0IS22029aOTvGHT2fbzcWKT6JmCxLp bshEvOmNiHDkAvBrvx+BeBhcD5dIg0n4uHm1gkBk46Ecb28i63c/bTiohrKuudKH69n2 OlV8xGhL61ydC5BDlhXlY4a14uQQsX0E0LQk3kLnRPEifpJ/8e0AOmXR/8bfTOS58bJx 9feiiopTnMypFzKGpnqI2UQ7dy/RjbRnMqqhrD3FPhV5xWa0NKIOfymwWeYYDhGQrAFY QMBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TZeM2sK6VsFpvnvIUwVCoNa4r1ezlmI7cS8ZgepmC84=; b=1G1HhzOQlh+W2l6GBlzXUnc11+Ia8FAr4op8zWs0nDv4ckRQuIR/PxFIsVA+FjplBI dsyTzMwIA+bibp3xn3/NVM13iXDgMLvpdFmaOopAWL3yo1kvuioMgp8JGt9PkvirtM8x UatuftcMnnJtsa9kZjXigubFoDXMdp1L+dUlY2OJeP8C7xw3H1hdwXGwEyiaD4kuhLq2 lD53rtRF8Vs1nU+c1cLi2AB5fz8ctpleXwSDovTMcSon7tUl7A851cwGJ/z3j5LJquTM 8dX5yBE44VwUj/cVnt2oAXJH+292LUDrxlvSAvb/CR880mwEYfpidf2vHZegLu69+AWz 063g== X-Gm-Message-State: AOAM5306stJ/21dooTwtRLWlX/RiHNebWsd+D0R8DJ13P0I4ZrOiuwWa B0hGAFGE5EQTvRGU+aS6OgjzQ2AIvjs2AX2ttIM= X-Google-Smtp-Source: ABdhPJxvA9Fb4Ot25FQ7DBPpMBdU2Pgp5GXz/X+0YUQRxuVvUiMLwiagK2c2Wbwd9yqwWpMY4qmw+LrtMOiu2XatiOE= X-Received: by 2002:a1f:a146:0:b0:34e:1514:c124 with SMTP id k67-20020a1fa146000000b0034e1514c124mr5732956vke.33.1651652450400; Wed, 04 May 2022 01:20:50 -0700 (PDT) MIME-Version: 1.0 References: <20220503155913.GA1187610@paulmck-ThinkPad-P17-Gen-1> <20220503163905.GM1790663@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: From: Michel Lespinasse Date: Wed, 4 May 2022 01:20:39 -0700 Message-ID: Subject: Re: Memory allocation on speculative fastpaths To: Matthew Wilcox Cc: "Paul E. McKenney" , Michal Hocko , Liam Howlett , hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Davidlohr Bueso , David Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: zoc3sc9ohoshtgt3iscxqjybg4cct7um X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 602AE140076 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=hSNZbMrT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of walken.cr@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=walken.cr@gmail.com X-HE-Tag: 1651652446-553894 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: (for context, this came up during a discussion of speculative page faults implementation details) On Tue, May 3, 2022 at 11:28 AM Matthew Wilcox wrote: > Johannes (I think it was?) made the point to me that if we have another > task very slowly freeing memory, a task in this path can take advantage > of that other task's hard work and never go into reclaim. So the > approach we should take is: > > p4d_alloc(GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN); > pud_alloc(GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN); > pmd_alloc(GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN); > > if (failure) { > rcu_read_unlock(); > do_reclaim(); > return FAULT_FLAG_RETRY; > } I don't think this works. The problem with allocating page tables is not just that it may break an rcu-locked code section; you also need the code inserting the new page tables into the mm's page table tree to synchronize with any munmap() that may be concurrently running. RCU isn't sufficient here, and we would need a proper lock when wiring new page tables (current code relies on mmap lock for this). > ... but all this is now moot since the approach we agreed to yesterday > is: > > rcu_read_lock(); > vma = vma_lookup(); > if (down_read_trylock(&vma->sem)) { > rcu_read_unlock(); > } else { > rcu_read_unlock(); > mmap_read_lock(mm); > vma = vma_lookup(); > down_read(&vma->sem); > } > > ... and we then execute the page table allocation under the protection of > the vma->sem. > > At least, that's what I think we agreed to yesterday. I don't remember discussing any of this yesterday. As I remember it, the discussion was about having one large RCU section vs several small ones linked by sequence count checks to verify the validity of the vma at the start of each RCU section.