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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 48115C4338F for ; Fri, 6 Aug 2021 04:34:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CBBD1611CC for ; Fri, 6 Aug 2021 04:34:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CBBD1611CC Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5DC146B0071; Fri, 6 Aug 2021 00:34:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58BE06B0072; Fri, 6 Aug 2021 00:34:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47B6A6B0073; Fri, 6 Aug 2021 00:34:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) by kanga.kvack.org (Postfix) with ESMTP id 2F5426B0071 for ; Fri, 6 Aug 2021 00:34:25 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D01E418EE9 for ; Fri, 6 Aug 2021 04:34:24 +0000 (UTC) X-FDA: 78443389248.20.9262B2E Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 859F75041700 for ; Fri, 6 Aug 2021 04:34:24 +0000 (UTC) Received: by mail-oi1-f171.google.com with SMTP id o185so10413279oih.13 for ; Thu, 05 Aug 2021 21:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=zoxn86tI0OeId1+HsMFj7XfTnI0a8mb/MBGQLX/EXMQ=; b=vHJ6XPyUZn6HJNpOvReBw9udckcsYokef5di4Syl6LKnkAactsc4UI9tj9lhQKRc0p i/+4HPQobOZvRyjNn4Zebf2F1yOcSKsOn5V8tBuYKsk+PFIOtt1jrMEl8xd9Ztx5wzIT n1MAnsVD+YiW8TTm0+g7+a2VsbVcGvGNym6KWmauxtV7zjI5v3XCM763w7dEODDSFNa4 uQvcfkiiE2EZApZ+s4qyMeJUKiqubOkwcYJT9ybNscj3gYQHSv5qHjzvedj9jcAMlbI6 Hf1bmO06V/2hWuag9tcb5QyIhNQNwLNAoczuTesYJsa7F0HDtlZdIRlHkTJLI4nHQAol 9/kQ== 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:in-reply-to:message-id :references:mime-version; bh=zoxn86tI0OeId1+HsMFj7XfTnI0a8mb/MBGQLX/EXMQ=; b=lB3j02hJ7sXLYbO38ywaXemOw96puB/jGw5aHiK77410OZpTVSlTQoCQuxF+1ouxUR kOoc71x+RKBpXyLHgwsxM4Q+wslZRmBB4SWPypnmACJAp8S8ivRGN3jFz0JhIFwopwdQ kRd2AW7aQEdoGK3qg/iehg/snBvXqR9VcVRlyqXN7FzdKUj4wHbHYHecHv7GaHcgslp/ vBNSfM1MxBjRs5VB19SfHOpnWUIAS0TSXxqCZdjSFGYmtaMBial1bn3pWzqGX5xNzWcB mr0HLtDTZCauXOAzYo3f8wNawDLTLvDsQMtSN3mg7bnwTmOnMg/x8MVOaEnwodsNypaQ asQg== X-Gm-Message-State: AOAM533hCtf53BNVQ7IoI/H1dGV+MSLdG76GW3mjre+H3mPcYYpXOVMc c83HgYm+0mufNTu/9zvtynF1Ew== X-Google-Smtp-Source: ABdhPJy5u56QxNQUqymSFnehqcKPsPChropjc6cHc2YkxdrkZ0dZqTbexTDkIM8YqLF7bAvQLHej5w== X-Received: by 2002:aca:b909:: with SMTP id j9mr13116203oif.9.1628224463623; Thu, 05 Aug 2021 21:34:23 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id n1sm1358979otk.34.2021.08.05.21.34.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Aug 2021 21:34:22 -0700 (PDT) Date: Thu, 5 Aug 2021 21:34:20 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: "Kirill A. Shutemov" cc: Hugh Dickins , Andrew Morton , Shakeel Butt , "Kirill A. Shutemov" , Yang Shi , Miaohe Lin , Mike Kravetz , Michal Hocko , Rik van Riel , Christoph Hellwig , Matthew Wilcox , "Eric W. Biederman" , Alexey Gladkov , Chris Wilson , Matthew Auld , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 08/16] huge tmpfs: fcntl(fd, F_HUGEPAGE) and fcntl(fd, F_NOHUGEPAGE) In-Reply-To: <20210804140805.vpuerwaiqtcvc5or@box.shutemov.name> Message-ID: References: <2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com> <1c32c75b-095-22f0-aee3-30a44d4a4744@google.com> <20210804140805.vpuerwaiqtcvc5or@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=vHJ6XPyU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of hughd@google.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=hughd@google.com X-Stat-Signature: h5gra9wxckxb7dwm4pnotwhjudkpfrez X-Rspamd-Queue-Id: 859F75041700 X-Rspamd-Server: rspam01 X-HE-Tag: 1628224464-746973 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, 4 Aug 2021, Kirill A. Shutemov wrote: > On Fri, Jul 30, 2021 at 12:48:33AM -0700, Hugh Dickins wrote: > > Add support for fcntl(fd, F_HUGEPAGE) and fcntl(fd, F_NOHUGEPAGE), to > > select hugeness per file: useful to override the default hugeness of the > > shmem mount, when occasionally needing to store a hugepage file in a > > smallpage mount or vice versa. > > Hm. But why is the new MFD_* needed if the fcntl() can do the same. That I've just addressed in the MFD_HUGEPAGE 07/16 thread. > > > These fcntls just specify whether or not to try for huge pages when > > allocating to the object later: F_HUGEPAGE does not touch small pages > > already allocated (though khugepaged may do so when the file is mapped > > afterwards), F_NOHUGEPAGE does not split huge pages already allocated. > > > > Why fcntl? Because it's already in use (for sealing) on memfds; and I'm > > anxious to keep this simple, just applying it to whole files: fallocate, > > madvise and posix_fadvise each involve a range, which would need a new > > kind of tree attached to the inode for proper support. > > Most of fadvise() operations ignore the range. I like fadvise() because > it's less prescriptive: kernel is free to ignore it. As to ignoring the range, yes, I see now that some do; and I'm relieved to see "Len == 0 means as much as possible", that's great, I was afraid of compat bugs over 0xffy numbers for the len. And we would want, not to ignore the range, but insist on offset 0, len 0 for now, if there's any intention (not mine) of extending it to ranges in the future. As to ignoring the prescription, that's just a matter of how we describe it in the manpage, no matter whether it's fadvise() or fcntl(). And in the 07/16 thread you also said: > > If a tunable needed, I would rather go with fadvise(). It would operate on > a couple of bits per struct file and they get translated into VM_HUGEPAGE > and VM_NOHUGEPAGE on mmap(). Not so sure about that detail: the point here is to decide what kind of allocations to try for, before the file is mmap()ed; and it is the file (the underlying object) that I want to condition here, rather than the struct file of who has it open at the time, or their mmap()s. But adding the flags into the vm_flags on mmap(): that's an interesting idea, I haven't played with that at all. Offhand, I don't think it will give different allocation results from what I'm already doing, but might affect what is shown by default in /proc//smaps. > > Later if needed fadvise() implementation may be extended to track > requested ranges. But initially it can be simple. I still prefer fcntl() myself, but we can go with either: what I'd like to hear is the preference of linux-fsdevel and linux-api people. Aside from the unused offset+len, my main problem with fadvise() is that... it doesn't exist. It's posix_fadvise() or fadvise64() or fadvise64_64(), and all its good advices are POSIX_MADV_whatever. Are we comfortable now adding LINUX_MADV_HUGEPAGE, LINUX_MADV_NOHUGEPAGE? I find myself singing 64 64 Zoo Lane. Hugh