Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3503985pxb; Mon, 24 Jan 2022 10:56:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJzRXeHC1/e6JC3Ehcwiy4vSROF0/xjnP7DU8oBEg1u4b5ERmpeLQv3IBOCCtSMG0A4wxXiq X-Received: by 2002:a17:90b:4f84:: with SMTP id qe4mr3260545pjb.24.1643050607367; Mon, 24 Jan 2022 10:56:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643050607; cv=none; d=google.com; s=arc-20160816; b=GCUrdtHqgSBx4z95DOB5A6jt0WC5aPfMTVahiDcYpf9jVTCRRXpwlf3EMprDxDEB7D jp9qgaOsbFEi4+QjQuu/jcURLJv51Q5109KIXJglP1t33AcfZ+ueAvPcIBTc4wHNL+rT tdyF6k483c98GfFk9oXGPlJCxc27uRBim/4RRvEnfMi+Y8CziD1NhHZF+en/hPQ3KAz/ j1OQvn98CqSno95JvRoTgYkly1oSOjQEFecT30+0zFmI7BwQnEKBy1XJA5sPqk65+ZsQ gO1t9jfvrynQWgDA3aGofFXKkIkYB6gTnIdyBIYBl0wxuqMIFlY4qGIjNSyynO/mfYV/ Ctyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=q/cJ3iWSzk/L9pl1h0bSd2z9dkOZnVgBJiwkxutziMY=; b=bWjJcwWFFN5hGhdUaM4j9dYP2/NqO1WmG8hhsnvfuDC+rS1CEqFfsqBmvJXXOSDCrG VdwDgemXpnPCz9tSESe3m4H8pMzzAVZUS9XuJnINr0LAk+j9u9rBpcx7mw6SqDpBkBuX NUNKKAKcXHbGCMIdYdVbiB779509GgnWiJ/woDl6VxQ5CY63g9SCepCJBiK8vPf/XjSB 9nDKaCGEL9S25KXyOceJxrqKma+SHLdwKWC1vEzFBGybvwlIyEIISoOls6U14MWLLYWX GDim+THJOI7sk9w2j5EIF2Lzg4b/4hAZAHAJvtvjxsmBOUJwJZVxXxKsw0K8wru4Z+sU aVug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Cxb/oXBh"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si12718453plk.379.2022.01.24.10.56.35; Mon, 24 Jan 2022 10:56:47 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Cxb/oXBh"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbiAXJNf (ORCPT + 99 others); Mon, 24 Jan 2022 04:13:35 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:56910 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229474AbiAXJNe (ORCPT ); Mon, 24 Jan 2022 04:13:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643015614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q/cJ3iWSzk/L9pl1h0bSd2z9dkOZnVgBJiwkxutziMY=; b=Cxb/oXBhlURefpfXJwh1xVY3J7t0QghjHgPGKqwtMbwSTqHDjMdqRDTgF3Xh0Dsr2kaDyw aks8YMYlzq0ITUuSypsCb5lONBUKmWe/YJ5xPia+rdWqAr9605GgiI9DOZL+xkjvLjZ/JT W3ubR3ZqKdD20P5RnsX+O1MeCYLOdC0= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-340-QzfWNIUWMb-nqbsFMj47nA-1; Mon, 24 Jan 2022 04:13:32 -0500 X-MC-Unique: QzfWNIUWMb-nqbsFMj47nA-1 Received: by mail-pf1-f200.google.com with SMTP id u80-20020a627953000000b004c82105f20dso2002666pfc.11 for ; Mon, 24 Jan 2022 01:13:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q/cJ3iWSzk/L9pl1h0bSd2z9dkOZnVgBJiwkxutziMY=; b=wR0rEConOI+q81mtQm4lzCSfsgusvQfSNyIaj/KiJXAKn307EJdxYHxqnVVFtbnf/w WgRY0U3L1PwbA8fQIQYokhHQ7SxaPIoY8HquReOgAoeW8zX0q5/thxNKVIPnOuRqEl4Z IgNiG7JqgmKVpFnB7xzGUdW61eFaKVLfbQoYv5lpzPBmhGGDMhgSirDoQYVQv4ndhbdJ GeOp4ZT2nsmtWMfOc05kPszlhvOAIwJm9jlyjHK4oOQgQNEp69d5jMBKiYhPiPegeFzu o8DCwdYIhcFVpZLs3u/2cPMBem72eRR6YUf9hy4H8AktamdVCBtktebQWM5qPBoLrOGi 53zw== X-Gm-Message-State: AOAM532zO25Vv6Hq1k07lJ7v/wfVRm5/9HixINTJtoKTgRjrc6LAXt+1 ySgAx/kU324KLOli2C6jrqILAhV8Hvqj5APDZOVSFdHUXuWfRgIlQREPcy+FiToS0bhH+FxdoFM OnjnnLgoeMO1hLnRY0DU7egrY X-Received: by 2002:a17:90b:2406:: with SMTP id nr6mr966725pjb.99.1643015611587; Mon, 24 Jan 2022 01:13:31 -0800 (PST) X-Received: by 2002:a17:90b:2406:: with SMTP id nr6mr966711pjb.99.1643015611367; Mon, 24 Jan 2022 01:13:31 -0800 (PST) Received: from xz-m1.local ([94.177.118.73]) by smtp.gmail.com with ESMTPSA id s13sm4719075pfk.174.2022.01.24.01.13.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 01:13:30 -0800 (PST) Date: Mon, 24 Jan 2022 17:13:23 +0800 From: Peter Xu To: Hugh Dickins Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Andrea Arcangeli , Yang Shi , Vlastimil Babka , Andrew Morton , Alistair Popple , "Kirill A . Shutemov" , Matthew Wilcox Subject: Re: [PATCH RFC v2 1/2] mm: Don't skip swap entry even if zap_details specified Message-ID: References: <20211115134951.85286-1-peterx@redhat.com> <20211115134951.85286-2-peterx@redhat.com> <9937aaa-d9ab-2839-b0b7-691d85c9141@google.com> <391aa58d-ce84-9d4-d68d-d98a9c533255@google.com> <56e33192-965d-691a-afc-f77f5856afd@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56e33192-965d-691a-afc-f77f5856afd@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 23, 2022 at 10:51:57PM -0800, Hugh Dickins wrote: > I don't know of any problem that needs fixing with the zero page: > how do you suppose the zero page gets into a truncatable or hole-punchable > mapping? We use it for read faults in anonymous mappings. And I told the > story of how once-upon-a-time it could get inserted into any mapping by > reading from /dev/zero, but that odd case was dropped years ago. And I > am open to (even encouraging) a change to make use of zero page for read > faults of holes in shmem: but that's potential future work, which would > require some changes elsewhere (though perhaps none here: the zero page > could never be used for the result of a COW). > > Please explain the zero page problem you hope to fix here. After I tried to learn the old/new worlds of zero page somehow I thought there can be zero pfns installed, but it seems not at all.. Please ignore above, sorry for the noise. -- Peter Xu