Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3209164ybb; Mon, 13 Apr 2020 03:08:20 -0700 (PDT) X-Google-Smtp-Source: APiQypK72GpUvEJcj1QwugaptaVzXNDwb92bf5x/FG94n0sEp5a6yZJdvhL+936BGKSp3mkZdq1J X-Received: by 2002:a17:906:5248:: with SMTP id y8mr14208219ejm.129.1586772500054; Mon, 13 Apr 2020 03:08:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586772500; cv=none; d=google.com; s=arc-20160816; b=y8DtfVJsT8amaVivdeXZleUiyCElyWfLbPwdkvUdGw0wTEdpWILBeOkepKwHN+hxKn GT4cNiymH7g8vngskzMVuRsvVxeAUJoAFyrIfH/DQlZvKc/hQMP/FHCZrtqHID4nbJhz Ju9Vjm1vp+n1C0uwGKHtqI3nxm2z60Ne9/utX7hmrWtpB/Mkm8Bzu3YrubYRWIhugv6t FdUTyqr87QXT5Hm9+lIdwV+LPtXU35imw/XL/26r/gKkjoR/0ULb/HVNDdYS9VMddKZH P6NhySE35t0/XaDAxCGpHcMf9n8xkXfH90JUJM0I/ScjBOAuPFUxBFwAMgIqFltSp+Ps /mvA== 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=5EVtSWTpW2gBZAVG9ya8rnghhWuRsTFGgq4qSDI6w6g=; b=fMvUOaYlbLKMbGKVxTk0hdyhE3teJ7+m4wUJOGG0lwqW4mkrq7FMbMjph/xpgPlfbT BQiqrz2nHAMMHaLm36TPA+0BnZXQolqsYtW3UeEaBdskRmfhPhJ1Q0dVdDQ6582NL1zp bKMBk3QtMMJZdOPjYQVA8op0JUSB43oSoYQk8es1igN1jJ1NnKWWBAXM9xwRumKng/Nj 2OECugc32KWZOL0APxSP1ux6erej/38h2k9vAi4PlO2TCzgcWX0ZBMq4XMcCS/U0amku G8MDgXyyFK5dKd1hXvJDktfV6AZeMInvvY50r4USPT3Wh7wvtlHP8xMijb5uZjLw/CgU 12ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=SuIpP+w+; spf=pass (google.com: best guess record for 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 y6si6126582eds.303.2020.04.13.03.07.56; Mon, 13 Apr 2020 03:08:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for 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=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=SuIpP+w+; spf=pass (google.com: best guess record for 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 S1728453AbgDMJtm (ORCPT + 99 others); Mon, 13 Apr 2020 05:49:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728015AbgDMJtl (ORCPT ); Mon, 13 Apr 2020 05:49:41 -0400 X-Greylist: delayed 456 seconds by postgrey-1.27 at vger.kernel.org; Mon, 13 Apr 2020 05:49:41 EDT Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44430C0A3BDC for ; Mon, 13 Apr 2020 02:42:05 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v9so1494514ljk.12 for ; Mon, 13 Apr 2020 02:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5EVtSWTpW2gBZAVG9ya8rnghhWuRsTFGgq4qSDI6w6g=; b=SuIpP+w+r+qMR9OHa1Bp4wwQC6uIAMRhhzW1Rxk6cHq3gO6nqkA/hulf5DEzztSqHj wJGe77kLD8NMfLQM2zJFSUm87BD9GW75pydTfyd8u5BIoeV6jtQXVV2/pHN2Ht9uU023 y/i/hZ7v/Hf4OlnIWGwLF9DBtOGONHZQ/Cg6tUC0fKaFhcdewe1idzlJfSm6ZGvqXG0Z W2ZjDUDM39RS8HYJty0vc8/pmg/NR79rTnfgHGb1Eb2QCUFdazEtbTlht6CzuAdoHpyo XRgBuPYVHrBfi/+Yira39hWBe8qpUKC3Vx2kOh3x+YSo0wLceegv8XcUif+My7kdIy5e gWuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5EVtSWTpW2gBZAVG9ya8rnghhWuRsTFGgq4qSDI6w6g=; b=Qj8vB+toSvTsIh95m8KIIED2q2uUY7mjmuGlj9OcqcbTne0sKEaVGjuyZK8byivU5d s9gE9WNbXso92n+5B6oXEHjbNQ6W612ubMp1zE789ut0/fVA2UvIAhQsq3atYNe96Hzy bw+DPR2wLyAg0ZF9isA1XIzx1oQledYgbwYgfFcgBkdIULzT7NEJoKM5UFxhqWC2+JvP hSl6AMPFYMN8M/GOryA9QA2B5WyQpRULGLGYPjZkntJhJbliGFzLARSPyi6PC9UFPgnl XOiw2W9v432JBcBEAM2iGdcoQmNgfQbK6SKOytpMVu4SL45wx6fjQaXmvaLbhPEQulRb TzMg== X-Gm-Message-State: AGi0PubAks3HqZEMhIJGwIZdZCI1vKEXnOHli2Whbn+r7Jg87irBp+f9 7/xbDuX9+3M3oNFpljicdGhv3g== X-Received: by 2002:a2e:140d:: with SMTP id u13mr1384446ljd.152.1586770923586; Mon, 13 Apr 2020 02:42:03 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id a15sm6720609ljp.44.2020.04.13.02.42.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2020 02:42:02 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 7840210230F; Mon, 13 Apr 2020 12:42:04 +0300 (+03) Date: Mon, 13 Apr 2020 12:42:04 +0300 From: "Kirill A. Shutemov" To: John Hubbard Cc: akpm@linux-foundation.org, Andrea Arcangeli , Zi Yan , Yang Shi , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [PATCHv2 5/8] khugepaged: Allow to callapse a page shared across fork Message-ID: <20200413094204.a2gpsjhugy5dznjy@box> References: <20200403112928.19742-1-kirill.shutemov@linux.intel.com> <20200403112928.19742-6-kirill.shutemov@linux.intel.com> <5a57635b-ed75-8f09-6f0c-5623f557fc55@nvidia.com> <20200410155543.i66uz6pbynfvkhak@box> 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 Fri, Apr 10, 2020 at 01:59:22PM -0700, John Hubbard wrote: > I think I understood what you were saying. The problem is that was ignoring > a couple of points, especially in an RDMA situation: 1) the page can be > pinned by various drivers, on behalf of other processes, even if the original > process is being torn down, and 2) it doesn't really matter which process pins > a page--the end result is that it's pinned. Well, no. It is critical that nobody gets new pins after this point on behalf of *this* process as we about change what is mapped on this virtual address range. We must avoid the situation that khugepaged screws legitimate GUP users and make what process see differs from what GUP see. Pins on behalf of other processes after the point are not relevant to us. I will keep the comment as is for now. As you can see I'm struggling communicating my point. Any better wording is welcome. -- Kirill A. Shutemov