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=-10.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,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 D5E4FC433DB for ; Tue, 23 Mar 2021 17:13:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 81640619B2 for ; Tue, 23 Mar 2021 17:13:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81640619B2 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1A1796B0119; Tue, 23 Mar 2021 13:13:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1778A6B024E; Tue, 23 Mar 2021 13:13:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F34436B024F; Tue, 23 Mar 2021 13:13:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id D7D336B0119 for ; Tue, 23 Mar 2021 13:13:33 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8930E1801C392 for ; Tue, 23 Mar 2021 17:13:33 +0000 (UTC) X-FDA: 77951785506.02.E79A583 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf03.hostedemail.com (Postfix) with ESMTP id E9EA0C000C52 for ; Tue, 23 Mar 2021 17:13:28 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id i26so11878887lfl.1 for ; Tue, 23 Mar 2021 10:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2TirXFZY2jPaEL0KWhVIwGSMq8Y4H6hJmyZW6Jxtc0A=; b=mWBywyhskyYDqBeIRiQcumwxdOErorKw60zVG9sUeSZ4Z16mvYuTAi/dZo96Fj2YvV YeMMc/L0eExx33jMYhlWr7OFB84u4VTJRgJXhVAj2bNvDt04rcKGXuH5hMHDPDt5vCA0 hZKcYbP1vGqwP1oZ/gMJxw/Wcr4IgPKdRGm4zaQ9S4Bb9YDpuVe6p2lfP4X/qioHxzDj ZNLzhOHDfw9f6n0sxJmH264VIiy1vYHkCC+djoBhWT+MMImYbUpQznZw6RuegxOFkClj hL48CXz069qmlWsV5SpZwwSROZBhjmPISwjcAO7BmYLL5XMMsBXK1Ek04ooW9c7i82Gy +8dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2TirXFZY2jPaEL0KWhVIwGSMq8Y4H6hJmyZW6Jxtc0A=; b=CRf5PHMCl4RAv0emWOUayNigu54LJ8WrpCP18VsGRsBuyWU474me5hcJ2KCJD4W2Os Kg4K5dZ/5vHG4x9fdBRme7ehlTLYiv0O4VgiFsBn9RxFWfu5z59UdNQSQ7i9FaZg+WVw zagutg4GE4bfwNk8BpWoH1X/fju/FfXuCwo4HXS2Kdzq9iijROVHmCkw4twwJkVgVCvE XWDzxEO/tfd5DaI3GZ5d1VkwXnahPBBmUTvUwn3D5Tz/pKQ/qylUggVeN/sbAuCa+m5L Eo6MW9NnXxWQ/exWaJIml4LRvyZOcO2odEf0qzYxSaVSQDN0zbLU/ph6F2iDC+7rM7J0 HcKA== X-Gm-Message-State: AOAM531nwKKBmsRech6Eajg/LGKIV/nVXG5zPi/c/WQgJfL/UrP7WqYR 5HWSQbhsdvoiEIS15ZQHe8LbVjqQwPxntvcHG4chPQ== X-Google-Smtp-Source: ABdhPJz3c4v3ZMSqUFoUhsoip2RhTW8k/ISpGq+PH/G9n64WmCw8u8+GTSbFZFpKCiqfjtipL+xjBDocR6ufTaW1ouU= X-Received: by 2002:a19:7618:: with SMTP id c24mr3185772lff.312.1616519606708; Tue, 23 Mar 2021 10:13:26 -0700 (PDT) MIME-Version: 1.0 References: <20210322215823.962758-1-cfijalkovich@google.com> In-Reply-To: From: Collin Fijalkovich Date: Tue, 23 Mar 2021 10:13:15 -0700 Message-ID: Subject: Re: [PATCH] mm, thp: Relax the VM_DENYWRITE constraint on file-backed THPs To: Song Liu Cc: Song Liu , Suren Baghdasaryan , Hridya Valsaraju , Kalesh Singh , Hugh Dickins , Tim Murray , Alexander Viro , Andrew Morton , Linux-Fsdevel , open list , Linux-MM Content-Type: multipart/alternative; boundary="000000000000ee893805be374cc1" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E9EA0C000C52 X-Stat-Signature: tw86sk4wgbt7j73c7hzhqk4aw7x5ewng Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-lf1-f52.google.com; client-ip=209.85.167.52 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616519608-560802 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: --000000000000ee893805be374cc1 Content-Type: text/plain; charset="UTF-8" > > Question: when we use this on shared library, the library is still > writable. When the > shared library is opened for write, these pages will refault in as 4kB > pages, right? That's correct, while a file is opened for write it will refault into 4kB pages and block use of THPs. Once all writers complete (i_writecount <=0), the file can fault into THPs again and khugepaged can collapse existing page ranges provided that it can successfully allocate new huge pages. From, Collin On Mon, Mar 22, 2021 at 4:55 PM Song Liu wrote: > On Mon, Mar 22, 2021 at 3:00 PM Collin Fijalkovich > wrote: > > > > Transparent huge pages are supported for read-only non-shmem filesystems, > > but are only used for vmas with VM_DENYWRITE. This condition ensures that > > file THPs are protected from writes while an application is running > > (ETXTBSY). Any existing file THPs are then dropped from the page cache > > when a file is opened for write in do_dentry_open(). Since sys_mmap > > ignores MAP_DENYWRITE, this constrains the use of file THPs to vmas > > produced by execve(). > > > > Systems that make heavy use of shared libraries (e.g. Android) are unable > > to apply VM_DENYWRITE through the dynamic linker, preventing them from > > benefiting from the resultant reduced contention on the TLB. > > > > This patch reduces the constraint on file THPs allowing use with any > > executable mapping from a file not opened for write (see > > inode_is_open_for_write()). It also introduces additional conditions to > > ensure that files opened for write will never be backed by file THPs. > > Thanks for working on this. We could also use this in many data center > workloads. > > Question: when we use this on shared library, the library is still > writable. When the > shared library is opened for write, these pages will refault in as 4kB > pages, right? > > Thanks, > Song > --000000000000ee893805be374cc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Question= : when we use this on shared library, the library is still
writable. Whe= n the
shared library is opened for write, these pages will refault in as= 4kB
pages, right?=C2=A0

That's corr= ect, while a file is opened for write it will refault into 4kB pages and bl= ock use of THPs. Once all writers complete (i_writecount <=3D0), the fil= e can fault into THPs again and khugepaged can collapse existing page range= s provided that it can successfully allocate new huge pages.

=
From,
Collin=C2=A0

On Mon, Mar 22, 2021 at 4:55 P= M Song Liu <song@kernel.org> w= rote:
On Mon, Ma= r 22, 2021 at 3:00 PM Collin Fijalkovich
<cfijalkovi= ch@google.com> wrote:
>
> Transparent huge pages are supported for read-only non-shmem filesyste= ms,
> but are only used for vmas with VM_DENYWRITE. This condition ensures t= hat
> file THPs are protected from writes while an application is running > (ETXTBSY).=C2=A0 Any existing file THPs are then dropped from the page= cache
> when a file is opened for write in do_dentry_open(). Since sys_mmap > ignores MAP_DENYWRITE, this constrains the use of file THPs to vmas > produced by execve().
>
> Systems that make heavy use of shared libraries (e.g. Android) are una= ble
> to apply VM_DENYWRITE through the dynamic linker, preventing them from=
> benefiting from the resultant reduced contention on the TLB.
>
> This patch reduces the constraint on file THPs allowing use with any > executable mapping from a file not opened for write (see
> inode_is_open_for_write()). It also introduces additional conditions t= o
> ensure that files opened for write will never be backed by file THPs.<= br>
Thanks for working on this. We could also use this in many data center
workloads.

Question: when we use this on shared library, the library is still
writable. When the
shared library is opened for write, these pages will refault in as 4kB
pages, right?

Thanks,
Song
--000000000000ee893805be374cc1--