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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 A25C9CA9EA0 for ; Wed, 23 Oct 2019 02:58:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 635A32086D for ; Wed, 23 Oct 2019 02:58:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="ajFwd5JQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 635A32086D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 006EC6B0003; Tue, 22 Oct 2019 22:58:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF90D6B0006; Tue, 22 Oct 2019 22:58:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE7876B0007; Tue, 22 Oct 2019 22:58:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id B7DAA6B0003 for ; Tue, 22 Oct 2019 22:58:09 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 6C9D7640E for ; Wed, 23 Oct 2019 02:58:09 +0000 (UTC) X-FDA: 76073540298.13.event12_4722aca15fe05 X-HE-Tag: event12_4722aca15fe05 X-Filterd-Recvd-Size: 6425 Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 02:58:08 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9N2rSK7067277; Wed, 23 Oct 2019 02:58:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=2Up8um5UIS0VhuMduC1NXXp0gaaP6t0HuUDLRAHsUvM=; b=ajFwd5JQWrXwpeiJePU8s4LEpwEIM1ib800J6VbMzBTS2mh+BaD0zzoKpk9EmGwry5bM O1gzfQUK9rJG3KFbRQKOU3dO0IgkwJDZBnLwfyE9SkKNL3fnN8W7UTyYEy9kaL+eX4ha 6GdJS+EdHxVJoSxOHEd0Jleda79vhMci8con7D/e0vbIbWlyp7JSOn0fsz/MJSwcfm/Q 0ktZJhLGkShucagqW05vM/fRTN3rQqi2dZcu3PlRbIQVkl1qTYpjs+/qXdVnaAXkSqEm f7zbIuCJWfVy+HgJkaVFXgXC+jXbOSO0Wuu+mOprFZB4RRAz/VxsdJID9vaUk52IBcxO Ng== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2vqswtjh57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 02:58:05 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9N2rDGj098504; Wed, 23 Oct 2019 02:56:04 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2vsx242q9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 02:56:04 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9N2tx9r002359; Wed, 23 Oct 2019 02:56:02 GMT Received: from [192.168.1.222] (/71.63.128.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Oct 2019 19:55:59 -0700 Subject: Re: [PATCH] hugetlbfs: add O_TMPFILE support To: Piotr Sarna Cc: Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org References: <22c29acf9c51dae17802e1b05c9e5e4051448c5c.1571129593.git.p.sarna@tlen.pl> <20191015105055.GA24932@dhcp22.suse.cz> <766b4370-ba71-85a2-5a57-ca9ed7dc7870@oracle.com> From: Mike Kravetz Message-ID: Date: Tue, 22 Oct 2019 19:55:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9418 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230027 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9418 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230028 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/22/19 12:09 AM, Piotr Sarna wrote: > On 10/21/19 7:17 PM, Mike Kravetz wrote: >> On 10/15/19 4:37 PM, Mike Kravetz wrote: >>> On 10/15/19 3:50 AM, Michal Hocko wrote: >>>> On Tue 15-10-19 11:01:12, Piotr Sarna wrote: >>>>> With hugetlbfs, a common pattern for mapping anonymous huge pages >>>>> is to create a temporary file first. >>>> >>>> Really? I though that this is normally done by shmget(SHM_HUGETLB) or >>>> mmap(MAP_HUGETLB). Or maybe I misunderstood your definition on anonymous >>>> huge pages. >>>> >>>>> Currently libraries like >>>>> libhugetlbfs and seastar create these with a standard mkstemp+unlink >>>>> trick, >>> >>> I would guess that much of libhugetlbfs was writen before MAP_HUGETLB >>> was implemented. So, that is why it does not make (more) use of that >>> option. >>> >>> The implementation looks to be straight forward. However, I really do >>> not want to add more functionality to hugetlbfs unless there is specific >>> use case that needs it. >> >> It was not my intention to shut down discussion on this patch. I was just >> asking if there was a (new) use case for such a change. I am checking with >> our DB team as I seem to remember them using the create/unlink approach for >> hugetlbfs in one of their upcoming models. >> >> Is there a new use case you were thinking about? >> > > Oh, I indeed thought it was a shutdown. The use case I was thinking about was in Seastar, where the create+unlink trick is used for creating temporary files (in a generic way, not only for hugetlbfs). I simply intended to migrate it to a newer approach - O_TMPFILE. However, > for the specific case of hugetlbfs it indeed makes more sense to skip it and use mmap's MAP_HUGETLB, so perhaps it's not worth it to patch a perfectly good and stable file system just to provide a semi-useful flag support. My implementation of tmpfile for hugetlbfs is straightforward indeed, but the MAP_HUGETLB argument made me realize that it may not be worth the trouble - especially that MAP_HUGETLB is here since 2.6 and O_TMPFILE was introduced around v3.11, so the mmap way looks more portable. > > tldr: I'd be very happy to get my patch accepted, but the use case I had in mind can be easily solved with MAP_HUGETLB, so I don't insist. If you really are after something like 'anonymous memory' for Seastar, then MAP_HUGETLB would be the better approach. I'm still checking with Oracle DB team as they may have a use for O_TMPFILE in an upcoming release. In their use case, they want an open fd to work with. If it looks like they will proceed in this direction, we can work to get your patch moved forward. Thanks, -- Mike Kravetz