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 E326FC433F5 for ; Sat, 18 Dec 2021 18:38:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 182D16B0071; Sat, 18 Dec 2021 13:38:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 131456B0073; Sat, 18 Dec 2021 13:38:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3BED6B0074; Sat, 18 Dec 2021 13:38:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id E41446B0071 for ; Sat, 18 Dec 2021 13:38:05 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9E9258249980 for ; Sat, 18 Dec 2021 18:37:55 +0000 (UTC) X-FDA: 78931774110.16.CE02AD7 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf03.hostedemail.com (Postfix) with ESMTP id 303CE20039 for ; Sat, 18 Dec 2021 18:37:55 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id b7so20910583edd.6 for ; Sat, 18 Dec 2021 10:37:54 -0800 (PST) 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=DHTFz7y22Ngs5ZQxLbmaebOcqARcdRZHKk6yXTOe9EM=; b=KHty4RXfZaDHjvIjUqBBf0UyRMBkN3UgDjrhi6CiMCObmA+JHse/h1kJiaRhoWRtKw dFFzw5XLjSH0a0Il6X2AftPA7gnQoObE7o+xGFiCuH4xOSQXXRADfVxklzeySVgKlmNC urFD6ysEJPJWuyHHTwJcTUzaDAQFmO0eR2yh0= 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=DHTFz7y22Ngs5ZQxLbmaebOcqARcdRZHKk6yXTOe9EM=; b=8Ktl3wV99alSwoCkSbye8RI6yppTOkMxLrk4qzjn5oIFM+MzDVcNxOhALU1fD7FYzw 0dQRQTrIlrDZvCPCbYyyXmL2u8Ixvr+rMkqllLIjm313K7pZQu2/pT8wew4Qe76s85kH h7nXTfVc3khLI/iHl5D3mSa80rVCUkyHU2MxdABaMQuVKAJo5OtcYZCHRPQ6DAHF8oCn QZe1LCHHIWq3UCBLzgLOXBI7CljNxWRfYrFsli++ZHxIq/n8RlUdIBfdy4hlPwOZZzRG Vyv4KfNiCmcVt6gstD/aqPuw4rKE00gKx6CDMA9SxnMO6L1zat76MoS9PeBpeXA43eBz GglQ== X-Gm-Message-State: AOAM532V0Elo8lUy1t78JzCv+QE7kuciEO93AY0MYlB7knuMH3jkX8o3 mMr6duwuU1FZU10hl7FHNe5TnHesilGwuRVHMSU= X-Google-Smtp-Source: ABdhPJxAdbxQkE/h7SsS2td3x2gpRDifUNtTnkqtTxO7gyeZyRgqV98T0NjEG9GAWcU1LuwVbyuzIQ== X-Received: by 2002:a05:6402:5206:: with SMTP id s6mr8171811edd.286.1639852673570; Sat, 18 Dec 2021 10:37:53 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id a18sm4645137eds.42.2021.12.18.10.37.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Dec 2021 10:37:53 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id o20so20828550eds.10 for ; Sat, 18 Dec 2021 10:37:53 -0800 (PST) X-Received: by 2002:a5d:6211:: with SMTP id y17mr7008989wru.97.1639852662653; Sat, 18 Dec 2021 10:37:42 -0800 (PST) MIME-Version: 1.0 References: <02cf4dcf-74e8-9cbd-ffbf-8888f18a9e8a@redhat.com> <0aa27d7d-0db6-94ee-ca16-91d19997286b@redhat.com> <0de1a3cb-8286-15bd-aec1-2b284bf8918a@redhat.com> <719D2770-97EF-4CF5-81E6-056B0B55A996@vmware.com> In-Reply-To: From: Linus Torvalds Date: Sat, 18 Dec 2021 10:37:26 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) To: Matthew Wilcox Cc: Nadav Amit , David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 303CE20039 X-Stat-Signature: fq7ddygkktg9rbnej4jrwxgjoifkfupi Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=KHty4RXf; spf=pass (imf03.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1639852675-498904 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, Dec 17, 2021 at 9:03 PM Matthew Wilcox wrote: > > Why are we comparing page_count() against 1 and not 1 + PageLRU(page)? > Having a reference from the LRU should be expected. Is it because of > some race that we'd need to take the page lock to protect against? The LRU doesn't actually count towards a reference - the LRU list is maintained independently of the lifetime of the page (and is torn down on last release - which wouldn't work if the LRU list itself held a ref to the page). But atr least some of the code that gathers up pages to then put them on the LRU list takes a ref to the pages before passing them off, just to guarantee to keep them around during the operation. So yes, various things can increment page counts in a transitory manner. I still *much* prefer a reliable COW over one that doesn't happen enough. The page count can have these (on the whole fairly rare) blips. That's ok. The page count is still *reliable*, in ways that teh mapcount can never be. The mapcount fundamentally doesn't show "other non-mapped users". So Nadav is correct that unnecessary cow events will cause extra work (and the TLB flush is a good point - just marking a page writable as-is is much cheaper). But I'm looking at teh actual code, and the actual logic, and I am dismissign the whole mapcount games completely. David has a 10-patch series (plus one test) of complex, grotty, hard-to-understand code with new flags. I posted a patch that removed 10 lines, and fixes the problem case his test-case was designed for. I think that really speaks to the issues. My approach is *simpler* and a hell of a lot more robust. And as mentioned, I can explain it. And christ the thing I'm advocating for is WHAT WE ALREADY DO FOR 99.99% of all cases. Why? Because it's literally how the regular COW paths work TODAY. And we had benchmarks show performance improvements (or no movement at all) from when we made those changes. Not the downsides that people claim. It's only the THP paths that are broken (and possibly some individual mis-uses of GUP - people have mentioned virtio). So nbow people are trying to do a fragile, complex thing that was shown to be problematic for the common case, and they are doing it for the insanely rare case? When a ten-line removal patch fixes that one too? Linus PS. Yes, yes, that 10-line removal patch is obviously still not tested, it's still likely incomplete because the THP case needs to do the page-pinning logic on the other side too, so I'm very obviously over-simplifying. But the fact that the *normal* pages already do this correctly - and don't use mapcount - should really make people go "Hmm".