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 9A888C433F5 for ; Wed, 22 Sep 2021 23:49:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2F40A611CA for ; Wed, 22 Sep 2021 23:49:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2F40A611CA 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 A29EF6B0071; Wed, 22 Sep 2021 19:49:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D9A7940008; Wed, 22 Sep 2021 19:49:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A157940007; Wed, 22 Sep 2021 19:49:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 7DA716B0071 for ; Wed, 22 Sep 2021 19:49:43 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3ABD98249980 for ; Wed, 22 Sep 2021 23:49:43 +0000 (UTC) X-FDA: 78616854246.36.7137788 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf15.hostedemail.com (Postfix) with ESMTP id D9AFCD000096 for ; Wed, 22 Sep 2021 23:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632354582; 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=omSt3JLppABnkkTziz8DoRFcEud7eDSDemkN9abf1/s=; b=MXgnX4jiv6Kytjl/kwW06h2JLQUjsPk+GvKollQ4hdbJQrh3Dr6ZTjSea3WLan8XaypB62 WwTfhFVXXe+3LfdUu6Ae/aroTKQuH0G77ciTJlcD0m3R/R5YE/z5gbpuNzt7etbCv/kpFs vmjB8qw8YD8muuANwQK1GH+p0UrGQyw= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-383-oly6GUPyNTmOoR5sdU3hKg-1; Wed, 22 Sep 2021 19:49:40 -0400 X-MC-Unique: oly6GUPyNTmOoR5sdU3hKg-1 Received: by mail-qt1-f198.google.com with SMTP id w10-20020ac87e8a000000b002a68361412bso12869011qtj.7 for ; Wed, 22 Sep 2021 16:49:40 -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=omSt3JLppABnkkTziz8DoRFcEud7eDSDemkN9abf1/s=; b=GbXiEMiA2+WnnyB2JXVTUUmYJ0wZV/LFEv3W91zZ97Yfj92RF6hx0P8YzFQ1amEFzp ZKbzDWqXKQb2/XkziKc0UWnbO5WjSCSNERYdHB2u/wGubnUozoDvzxQGAYB3acgBNAJ6 RtugjqFk9jYhsfTzn8d4v08edwY1VyFMhr1J4moJ1j4kMpvv3xx86BAHqK0GDcX5qn2G wKSGB1K5huoXqgIr11cM5AB5tatg8GufH/HUlejWKZYZqsvi0zMbl5QN6nH35M0wTJR3 9Xy4mS4RTADjNd3yAGRywPEApE8o8800yxiYT4whlDJLCco/Qvd2kxSaP6ATCMy91qWC f5Vg== X-Gm-Message-State: AOAM530Lq4VnsSMvzHJR67z3SGR/Zhu/dYb9NTRiQRcRTqTeVBdfs/pA UIzDwZyImd8EiZDhs5R3GmNKTNdGoqaniiSN0ZVerMzRFxKUuU+2HxAzYk8Hkt10QNp73nohkqi FL92hoBPngfs= X-Received: by 2002:ad4:5569:: with SMTP id w9mr1775728qvy.52.1632354580066; Wed, 22 Sep 2021 16:49:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCdoM1GRE07kCEtSb93RXwmmhtccuFEOrQUiN2B6B068zbi1IqfsdT7iiHsx11Lp/nV+NgzA== X-Received: by 2002:ad4:5569:: with SMTP id w9mr1775718qvy.52.1632354579802; Wed, 22 Sep 2021 16:49:39 -0700 (PDT) Received: from t490s ([2607:fea8:56a2:9100::d3ec]) by smtp.gmail.com with ESMTPSA id v3sm2986083qkd.20.2021.09.22.16.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 16:49:38 -0700 (PDT) Date: Wed, 22 Sep 2021 19:49:37 -0400 From: Peter Xu To: Axel Rasmussen Cc: Andrew Morton , Shuah Khan , Linux MM , Linuxkselftest , LKML , James Houghton Subject: Re: [PATCH 1/3] userfaultfd/selftests: fix feature support detection Message-ID: References: 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 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MXgnX4ji; spf=none (imf15.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: rtzpxiehs3xdwednfpmusknhjodx7hxa X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D9AFCD000096 X-HE-Tag: 1632354582-10662 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000068, 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 03:29:42PM -0700, Axel Rasmussen wrote: > On Wed, Sep 22, 2021 at 2:52 PM Peter Xu wrote: > > > > 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. > > Right, except that our use case is even more similar to QEMU: the code > doing UFFDIO_CONTINUE / demand paging, and the code running the vCPUs, > are in the same process (same mm) - just different threads. I see. > > > > > 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). > > Yes, this would be convenient for our implementation too. :) There are > workarounds if the feature doesn't exist, but it would be nice to > have. Could I know what's the workaround? Normally if the workaround works solidly, then there's less need to introduce a kernel interface for that. Otherwise I'm glad to look into such a formal proposal. > It's also useful for memory poisoning, I think, if the host > decides some page(s) are "bad" and wants to intercept any future guest > accesses to those page(s). Curious: isn't hwpoison information come from MCEs; or say, host kernel side? Then I thought the host kernel will have full control of it already. Or there's other way that the host can try to detect some pages are going to be rotten? So the userspace can do something before the kernel handles those exceptions? -- Peter Xu