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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 03C35C43464 for ; Fri, 18 Sep 2020 21:00:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6C8DD221EC for ; Fri, 18 Sep 2020 21:00:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Aeps+abb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C8DD221EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D14026B008C; Fri, 18 Sep 2020 17:00:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC3966B0093; Fri, 18 Sep 2020 17:00:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB2B86B0095; Fri, 18 Sep 2020 17:00:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id A67446B008C for ; Fri, 18 Sep 2020 17:00:02 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 74D032C0C for ; Fri, 18 Sep 2020 21:00:02 +0000 (UTC) X-FDA: 77277399444.03.nerve50_5d01d812712e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 4970D28A4EA for ; Fri, 18 Sep 2020 21:00:02 +0000 (UTC) X-HE-Tag: nerve50_5d01d812712e X-Filterd-Recvd-Size: 5388 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Sep 2020 21:00:01 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id a22so6116037ljp.13 for ; Fri, 18 Sep 2020 14:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RxtbCThgxVa45d8lwoZdOST6U19+8PapeOdnxsf30mE=; b=Aeps+abbSb6m7OScrhyrKQIBoDCeK+uzMrv3p7Vi8SJ/tda0vxPKmQPaOM4yNIEufz 8DkpaRbmCzpsE1w2i3cUoaPaMb/XdqKl6aUzuP4YN1olvJC/m4GdtmBzz4kr19naytiB dlWxRm+0+lXXCrm1ySrIDJpp+J+NIirt0APGg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RxtbCThgxVa45d8lwoZdOST6U19+8PapeOdnxsf30mE=; b=YhpO9JUwFocffZFcRA8CCSVzZJH+viGasA9O56jFScG2tNca3ZXKW13E+ZCo9URpmG W0oUZUOQfNm9VKLcrLHbfT9EJ1M723L+pNHi9SDHNfKGAgRMGUBIa47/YmQ5FfOHjpgh bxzoNKASwtzWrzwzYMnCsxDmG+luczZGoemiMt28UK17pSFlKBu4ulwrnnXTn+gE+D7b QsuR8p0KaZ5FIxzdXhNHRhlGcMuCPb0UgAjzcWCu5t2zg1/XRCB93gIk6pwtmX3nIBT2 Szx1uvXaxkyqPMUH9x/ufI4ymqJ/+ZYGKxW9gfzOn7maD42bZ+1JCrYLq4dgM1sDi1FE YuqQ== X-Gm-Message-State: AOAM532tJbk5CDNfnXlUwB0i4HNRCrqyyhPmndDcZM46/1EOsAsv/A4q p0nlztVmng3+m9vsfDioBg1mu49wk2bkbQ== X-Google-Smtp-Source: ABdhPJwV3TUBQ4zzO3VfZ5lFKYZ49FG9OdqLDoRgdAkB729LJqf4MKYBMReb8Rl5FIMzAzTphhTb6Q== X-Received: by 2002:a2e:3619:: with SMTP id d25mr13068044lja.369.1600462799517; Fri, 18 Sep 2020 13:59:59 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id y11sm841127ljc.27.2020.09.18.13.59.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2020 13:59:58 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id y17so7547680lfa.8 for ; Fri, 18 Sep 2020 13:59:58 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr11107210lfd.105.1600462797703; Fri, 18 Sep 2020 13:59:57 -0700 (PDT) MIME-Version: 1.0 References: <20200915232238.GO1221970@ziepe.ca> <20200916174804.GC8409@ziepe.ca> <20200916184619.GB40154@xz-x1> <20200917112538.GD8409@ziepe.ca> <20200917193824.GL8409@ziepe.ca> <20200918164032.GA5962@xz-x1> <20200918173240.GY8409@ziepe.ca> <20200918204048.GC5962@xz-x1> In-Reply-To: <20200918204048.GC5962@xz-x1> From: Linus Torvalds Date: Fri, 18 Sep 2020 13:59:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification To: Peter Xu Cc: Jason Gunthorpe , John Hubbard , Leon Romanovsky , Linux-MM , Linux Kernel Mailing List , "Maya B . Gokhale" , Yang Shi , Marty Mcfadden , Kirill Shutemov , Oleg Nesterov , Jann Horn , Jan Kara , Kirill Tkhai , Andrea Arcangeli , Christoph Hellwig , Andrew Morton 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, Sep 18, 2020 at 1:41 PM Peter Xu wrote: > > What would be the result if we simply use GFP_ATOMIC? Would there be too many > pages to allocate in bulk for ATOMIC? It's very easy to run out of memory with GFP_ATOMIC, and also cause various nasty issues with networking (ie when you've depleted atomic memory, networking starts losing packets etc). So yeah, this code should not use GFP_ATOMIC, I think it just needs to drop and re-take the paeg table lock. Which is easy enough to do: returning a zero 'entry.val' already does that for other reasons, there's nothing magical about holding the lock here, there's no larger page table lock requirement. The main annoyance is that I think it means that copy_pte_range() would also have to have a special "preallocation page" thing for this case, so that it can drop the lock, do the allocation, and then take the lock again and return 0 (to repeat - now with the preallocation filled). Honestly, if we had a completely *reliable* sign of "this page is pinned", then I think the much nicer option would be to just say "pinned pages will not be copied at all". Kind of an implicit VM_DONTCOPY. (Or we'd do the reverse, and say "pinned pages stay pinned even in the child"). But that's not an option when the pinning test is a "maybe". Oh well. Linus