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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 DD16EC4338F for ; Wed, 4 Aug 2021 19:17:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 78BE561050 for ; Wed, 4 Aug 2021 19:17:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 78BE561050 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CCE6D8D0002; Wed, 4 Aug 2021 15:17:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7E248D0001; Wed, 4 Aug 2021 15:17:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B46D18D0002; Wed, 4 Aug 2021 15:17:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id 9AB738D0001 for ; Wed, 4 Aug 2021 15:17:58 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 48683253B7 for ; Wed, 4 Aug 2021 19:17:58 +0000 (UTC) X-FDA: 78438358236.33.81F0AE9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id C3BE3D01994E for ; Wed, 4 Aug 2021 19:17:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628104677; 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=AOuTInqWHm5JsxiufxPxrl3RhFGmVgLzFC5P9l0+9vM=; b=hr0JG4BMzLXVWoeTYveKgtj4V6ZIhuxbu1/4/wbocTq5XLiqCZ80iTdZHVnmorVlWD5HXl bu4cQ7K8GDWtQzO/Jixg/X9AC6jzeuSSanERlGKFwsZ48FI/MmncsKJvrXzAI7pOBveQPD iJb9GSdJ/8fxevchtvc2YC5d9s9HA3Y= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-446-2_OFLBe-M4SKDkoma3YPoA-1; Wed, 04 Aug 2021 15:17:54 -0400 X-MC-Unique: 2_OFLBe-M4SKDkoma3YPoA-1 Received: by mail-qk1-f199.google.com with SMTP id p123-20020a378d810000b02903ad5730c883so2600794qkd.22 for ; Wed, 04 Aug 2021 12:17:54 -0700 (PDT) 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=AOuTInqWHm5JsxiufxPxrl3RhFGmVgLzFC5P9l0+9vM=; b=PZOUWg4fypQNQI+AObrVbMB+LbKkszZeE/M+spwh1ykwRZ60nMiz4HulXM8etZegPr xNGzD5fo1x8/Pd7ilySqB+nnyXEVr85/Nnr40xXslVitqVA4qXgJU2GEjgDzhzBNzOgj gpGPCwVHdS99cXH9GlbKJTJgYhT//1Bl3CQjqbw/VSPPqKH8D1a3OqhUazDTwV/POrMi HDIbWsvY36dsEFMhEGU7/15a/zW2scu6qKJAEznO2In94d7qRWyZH3ZRnONZ+rdt15pA oEd+QyA5cc2mAYn7W2RuYCimGKgCL2nI5Dq6oikYrEx/ViARp4ut4S2TLnLwFA4SAKvO gQ5Q== X-Gm-Message-State: AOAM532FOI7tfdV3kjCNDmMgbgBEYjU+ZZyg15BHsgS7ucNFx/LeHsnL A+19EVx1ra4cAQXr8m7HV0PahSihzmQENrs1/CXAmv3+WkqyPkb3k2h3mHI1D3/JJSxwHHfvloQ 0D3BSZND54Do= X-Received: by 2002:ac8:1106:: with SMTP id c6mr1064938qtj.20.1628104673686; Wed, 04 Aug 2021 12:17:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/VPzU3MTG44ao6DOYRTTSzyp04c8qcvUclHsx6dvYvekjwEGCNaOIR/cWW1gAe6hROeaXLw== X-Received: by 2002:ac8:1106:: with SMTP id c6mr1064902qtj.20.1628104673462; Wed, 04 Aug 2021 12:17:53 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-92-76-70-75-133.dsl.bell.ca. [76.70.75.133]) by smtp.gmail.com with ESMTPSA id w14sm1821905qkm.81.2021.08.04.12.17.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 12:17:52 -0700 (PDT) Date: Wed, 4 Aug 2021 15:17:51 -0400 From: Peter Xu To: David Hildenbrand Cc: Tiberiu A Georgescu , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, christian.brauner@ubuntu.com, ebiederm@xmission.com, adobriyan@gmail.com, songmuchun@bytedance.com, axboe@kernel.dk, vincenzo.frascino@arm.com, catalin.marinas@arm.com, peterz@infradead.org, chinwen.chang@mediatek.com, linmiaohe@huawei.com, jannh@google.com, apopple@nvidia.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, ivan.teterevkov@nutanix.com, florian.schmidt@nutanix.com, carl.waldspurger@nutanix.com, jonathan.davies@nutanix.com Subject: Re: [PATCH 0/1] pagemap: swap location for shared pages Message-ID: References: <20210730160826.63785-1-tiberiu.georgescu@nutanix.com> <839e82f7-2c54-d1ef-8371-0a332a4cb447@redhat.com> MIME-Version: 1.0 In-Reply-To: <839e82f7-2c54-d1ef-8371-0a332a4cb447@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=hr0JG4BM; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C3BE3D01994E X-Stat-Signature: 35jck4jo393sesh9z8baxr3kasdees3h X-HE-Tag: 1628104677-272122 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 Wed, Aug 04, 2021 at 08:49:14PM +0200, David Hildenbrand wrote: > TBH, I tend to really dislike the PTE marker idea. IMHO, we shouldn't store > any state information regarding shared memory in per-process page tables: it > just doesn't make too much sense. > > And this is similar to SOFTDIRTY or UFFD_WP bits: this information actually > belongs to the shared file ("did *someone* write to this page", "is > *someone* interested into changes to that page", "is there something"). I > know, that screams for a completely different design in respect to these > features. > > I guess we start learning the hard way that shared memory is just different > and requires different interfaces than per-process page table interfaces we > have (pagemap, userfaultfd). > > I didn't have time to explore any alternatives yet, but I wonder if tracking > such stuff per an actual fd/memfd and not via process page tables is > actually the right and clean approach. There are certainly many issues to > solve, but conceptually to me it feels more natural to have these shared > memory features not mangled into process page tables. Yes, we can explore all the possibilities, I'm totally fine with it. I just want to say I still don't think when there's page cache then we must put all the page-relevant things into the page cache. They're shared by processes, but process can still have its own way to describe the relationship to that page in the cache, to me it's as simple as "we allow process A to write to page cache P", while "we don't allow process B to write to the same page" like the write bit. Swap information is indeed tricky because it's shared by all the processes, but so far I still see it as a doable approach as long as it can solve the problem. I am not against the approach mentioned in this patch either - but I still share my concerns, as that's not normally what we do with existing interfaces. Thanks, -- Peter Xu