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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01224C433EF for ; Fri, 11 Feb 2022 02:29:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DBE46B0074; Thu, 10 Feb 2022 21:29:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 48AD16B0075; Thu, 10 Feb 2022 21:29:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32AA76B0078; Thu, 10 Feb 2022 21:29:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 237606B0074 for ; Thu, 10 Feb 2022 21:29:00 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BE3E3944ED for ; Fri, 11 Feb 2022 02:28:59 +0000 (UTC) X-FDA: 79128916398.18.435525A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 45D3AA0003 for ; Fri, 11 Feb 2022 02:28:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644546538; 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=ZRXctwJeAQFVYjXrxuQmTAgJlVAm+rBpFurANrwaps0=; b=H3XA8RgUmdnr/P/bOzA8x8S2YUUPG1bxIFJOjoanIhyAFSv3D/0/Qvvz+HhXJVZNyDKVwW EVlBFwj1bHIfvshXKSubcKhKayXmeVHopjIjYZp6wokPtZJD2lxXka7/eCXLJObFSUfXXS AXiu8SJr7BHxheCYu5POqxloPbzWMS8= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-650-SFbn_WUXN6-mJx7biaWITg-1; Thu, 10 Feb 2022 21:28:57 -0500 X-MC-Unique: SFbn_WUXN6-mJx7biaWITg-1 Received: by mail-pj1-f72.google.com with SMTP id ml24-20020a17090b361800b001b8877a4b6eso4964159pjb.5 for ; Thu, 10 Feb 2022 18:28:57 -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=ZRXctwJeAQFVYjXrxuQmTAgJlVAm+rBpFurANrwaps0=; b=qlYzSRD+LwJDCnrnZ4GEroKrKfikm5gzrjUN+GHLzvrQJwtViv4RbIBmktvRmsGdij KgeWBQDDAyZr/tfEdLsaGaK+f6cLvemcawI7gM15WDcs0ilrx5FomkVp2v//sPbk68YN ywKBTErW9pXo8B3YIs4BMGvcIoXed+X6N2XcoqbWRUpWRYvb2iwyd6ZTiMVTadrjZ/9i HlRTmVpoRE0BRkxprl8S9lenm/PD8hW3zlqw2lGPhnUxBZh9+o9Pj+Y/7yc4Qr5W0R+6 NQCXqItuU7+H8QDu7QWzWErqF54cR06dn9sfNErTgBqTPzQHzXza+5o+lxF7PsnxriPL 6N/A== X-Gm-Message-State: AOAM533SK+qHj6mcCxpCQ7Zj/dj0y1DLvtUgQ6C1znVTC0x6wDlCH1Cw rrG4QzgT0saa4Sg/q4vJQsuQfEzhqG4zBnqn5tvjyrZ1oIq9+QV3MdcV1DYrIKEkbk5/IdLf/Bi 7cCPDRkgtyYo= X-Received: by 2002:a17:90b:3509:: with SMTP id ls9mr395386pjb.119.1644546536295; Thu, 10 Feb 2022 18:28:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyKhpLjhur3uEYC/MkRKNPNhuN8BVtI9OKif4ZLj48t7oOtjhV+RYCcpM1wBjEQ2GppRv0/Q== X-Received: by 2002:a17:90b:3509:: with SMTP id ls9mr395358pjb.119.1644546535962; Thu, 10 Feb 2022 18:28:55 -0800 (PST) Received: from xz-m1.local ([94.177.118.150]) by smtp.gmail.com with ESMTPSA id q1sm8172622pfs.112.2022.02.10.18.28.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Feb 2022 18:28:55 -0800 (PST) Date: Fri, 11 Feb 2022 10:28:49 +0800 From: Peter Xu To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Naoya Horiguchi , David Hildenbrand , Axel Rasmussen , Mina Almasry , Michal Hocko , Andrea Arcangeli , Shuah Khan , Andrew Morton Subject: Re: [PATCH v2 1/3] mm: enable MADV_DONTNEED for hugetlb mappings Message-ID: References: <20220202014034.182008-1-mike.kravetz@oracle.com> <20220202014034.182008-2-mike.kravetz@oracle.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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 45D3AA0003 X-Stat-Signature: 8s5wrjz9fqtufgqp8d1eic5a446di8mb Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=H3XA8RgU; spf=none (imf25.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-Rspam-User: X-HE-Tag: 1644546539-456681 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 Thu, Feb 10, 2022 at 01:36:57PM -0800, Mike Kravetz wrote: > > Another use case of DONTNEED upon hugetlbfs could be uffd-minor, because afaiu > > this is the only api that can force strip the hugetlb mapped pgtable without > > losing pagecache data. > > Correct. However, I do not know if uffd-minor users would ever want to > do this. Perhaps? My understanding is before this patch uffd-minor upon hugetlbfs requires the huge file to be mapped twice, one to populate the content, then we'll be able to trap MINOR faults via the other mapping. Or we could munmap() the range and remap it again on the same file offset to drop the pgtables, I think. But that sounds tricky. MINOR faults only works with pgtables dropped. With DONTNEED upon hugetlbfs we can rely on one single mapping of the file, because we can explicitly drop the pgtables of hugetlbfs files without any other tricks. However I have no real use case of it. Initially I thought it could be useful for QEMU because QEMU migration routine is run with the same mm context with the hypervisor, so by default is doesn't have two mappings of the same guest memory. If QEMU wants to leverage minor faults, DONTNEED could help. However when I was measuring bitmap transfer (assuming that's what minor fault could help with qemu's postcopy) there some months ago I found it's not as slow as I thought at all.. Either I could have missed something, or we're facing different problems with what it is when uffd minor is firstly proposed by Axel. This is probably too out of topic, though.. Let me go back.. Said that, one thing I'm not sure about DONTNEED on hugetlb is whether this could further abuse DONTNEED, as the original POSIX definition is as simple as: The application expects that it will not access the specified address range in the near future. Linux did it by tearing down pgtable, which looks okay so far. It could be a bit more weird to apply it to hugetlbfs because from its definition it's a hint to page reclaims, however hugetlbfs is not a target of page reclaim, neither is it LRU-aware. It goes further into some MADV_ZAP styled syscall. I think it could still be fine as posix doesn't define that behavior specifically on hugetlb so it can be defined by Linux, but not sure whether there can be other implications. Thanks, -- Peter Xu