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=-7.2 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 0EB64C433EF for ; Wed, 22 Sep 2021 21:52:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9BE360FC1 for ; Wed, 22 Sep 2021 21:52:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A9BE360FC1 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 1B498900002; Wed, 22 Sep 2021 17:52:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13DAB6B0071; Wed, 22 Sep 2021 17:52:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2108900002; Wed, 22 Sep 2021 17:52:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id DDC606B006C for ; Wed, 22 Sep 2021 17:52:01 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8B3D11806F for ; Wed, 22 Sep 2021 21:52:01 +0000 (UTC) X-FDA: 78616557642.27.5CB8B61 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 1F25CE001980 for ; Wed, 22 Sep 2021 21:52:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632347520; 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=rYJ9XhtNZb7A4dQeqrhtvVfcVr5NXd1mHuE3OMC2z7c=; b=QcSEB5PhaAuXiwp890Pc1B+8qWbAevAfcYHS1L9EmaLdT0bAXX8Q0B2xBxSIcp4KcPptOP cqt+tTHtVx3eoh6+8VZdWslxMsgXscDgBPChLPLhSMu1RtVzsblH7K7V5yEi6EoyY1CfgV nadOd0OBh2due2vYxo3wj8YIXPfTqBE= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-567-RTPUoJNsMI-cck9TRfTiaw-1; Wed, 22 Sep 2021 17:51:57 -0400 X-MC-Unique: RTPUoJNsMI-cck9TRfTiaw-1 Received: by mail-qv1-f69.google.com with SMTP id l18-20020a056214039200b0037e4da8b408so14905667qvy.6 for ; Wed, 22 Sep 2021 14:51:57 -0700 (PDT) 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=rYJ9XhtNZb7A4dQeqrhtvVfcVr5NXd1mHuE3OMC2z7c=; b=AyL9Cm5Qe95B3FUr8/W8EyxE+Ll3cRlQmKrVK1VQj1pBhdiBToChat9SSpDX9af9Eh U0wFV9f6YJtIlteQGtqByTGJtQbaCv4PtOtXAXEA0xXdVaYtBfRT4NY/I8lMzHQsqVQ8 0YBuritculMrpGjT19XcopYvMgTr90KR9lfUT0Mnx9qNu3QErK1eVcggvr1V7NaTgpka LxzQIRaM7WT4Ra/jA4WuIOpNLjMTydXHBhPAJzUW7Tfvi7o6Y3DJHTu3JXveY50LumgO Tn4A7ABcNWi4pRmlQT97qQ6Q/puiFfQsH+bmtHbRXUP2r7BywDenz045BjoNWSITOkye xVOw== X-Gm-Message-State: AOAM533Y0ILMJT0wkegK4PPwAzHXmbEFOhK5cNSgDlE3ivuldKfRniAX PjfsqjrBY8DhZ3MPD9IR4IruR5WuTSgvLtJGiaUvEwL7zeW+3PR0aU4m87Rp7cwK4HzMy7ln78Q qLj6/WKRIpEM= X-Received: by 2002:a0c:f58b:: with SMTP id k11mr1146252qvm.66.1632347516593; Wed, 22 Sep 2021 14:51:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2vehWnx2IYD6qD1pTYUcyYrhr0SdnzxB6e0brzMk0zVjUL48IEuBmj1CjOE805HOCWLgE9g== X-Received: by 2002:a0c:f58b:: with SMTP id k11mr1146239qvm.66.1632347516309; Wed, 22 Sep 2021 14:51:56 -0700 (PDT) Received: from t490s ([2607:fea8:56a2:9100::d3ec]) by smtp.gmail.com with ESMTPSA id l13sm2742962qkp.97.2021.09.22.14.51.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 14:51:55 -0700 (PDT) Date: Wed, 22 Sep 2021 17:51:54 -0400 From: Peter Xu To: Axel Rasmussen Cc: Andrew Morton , Shuah Khan , Linux MM , Linuxkselftest , LKML Subject: Re: [PATCH 1/3] userfaultfd/selftests: fix feature support detection Message-ID: References: <20210921163323.944352-1-axelrasmussen@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: kcj5uknh3qepwou13x4q6soz8ednbzd6 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QcSEB5Ph; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf30.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1F25CE001980 X-HE-Tag: 1632347520-611096 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, Sep 22, 2021 at 01:54:53PM -0700, Axel Rasmussen wrote: > On Wed, Sep 22, 2021 at 10:33 AM Peter Xu wrote: > > > > Hello, Axel, > > > > On Wed, Sep 22, 2021 at 10:04:03AM -0700, Axel Rasmussen wrote: > > > Thanks for discussing the design Peter. I have some ideas which might > > > make for a nicer v2; I'll massage the code a bit and see what I can > > > come up with. > > > > Sure thing. Note again that as I don't have a strong opinion on that, feel > > free to keep it. However if you provide v2, I'll read. > > > > [off-topic below] > > > > Another thing I probably have forgot but need your confirmation is, when you > > worked on uffd minor mode, did you explicitly disable thp, or is it allowed? > > I gave a more detailed answer in the other thread, but: currently it > is allowed, but this was a bug / oversight on my part. :) THP collapse > can break the guarantees minor fault registration is trying to > provide. I've replied there: https://lore.kernel.org/linux-mm/YUueOUfoamxOvEyO@t490s/ We can try to keep the discussion unified there regarding this. > But there's another scenario: what if the collapse happened well > before registration happened? Maybe yes, but my understanding of the current uffd-minor scenario tells me that this is fine too. Meanwhile I actually have another idea regarding minor mode, please continue reading. Firstly, let me try to re-cap on how minor mode is used in your production systems: I believe there should have two processes A and B, if A is the main process, B could be the migration process. B migrates pages in the background, while A so far should have been stopped and never ran. When we want to start A, we should register A with uffd-minor upon the whole range (note: I think so far A does not have any pgtable mapped within uffd-minor range). Then any page access of A should kick B and asking "whether it is the latest page", if yes then UFFDIO_CONTINUE, if no then B modifies the page, plus UFFDIO_CONTINUE afterwards. Am I right above? So if that's the case, then A should have no page table at all. Then, is that a problem if the shmem file that A maps contains huge thps? I think no - because UFFDIO_CONTINUE will only install small pages. Let me know if I'm understanding it right above; I'll be happy to be corrected. Actually besides this scenario, I'm also thinking of another scenario of using minor fault in a single process - that's mostly what QEMU is doing right now, as QEMU has the vcpu threads and migration thread sharing a single mm/pgtable. So I think it'll be great to have a new madvise(MADV_ZAP) which will tear down all the file-backed memory pgtables of a specific range. I think it'll suite perfectly for the minor fault use case, and it can be used for other things too. Let me know what you think about this idea, and whether that'll help in your case too (e.g., if you worry a current process A mapped huge shmem thp somewhere, we can use madvise(MADV_ZAP) to drop it). > I *think* the existing code deals with THPs correctly in that case, but then > again I don't think our selftest really covers this case, and it's not > something I've tested in production either (to work around the other bug, we > currently MADV_NOHUGEPAGE the area until after VM demand paging completes, > and the UFFD registration is removed), so I am not super confident this is > the case. In all cases, enhancing the test program will always be welcomed. Thanks, -- Peter Xu