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,URIBL_BLOCKED,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 D6527C433DB for ; Tue, 30 Mar 2021 20:01:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50460619C2 for ; Tue, 30 Mar 2021 20:01:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50460619C2 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 A75E16B0080; Tue, 30 Mar 2021 16:01:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A27196B0081; Tue, 30 Mar 2021 16:01:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 877E96B0082; Tue, 30 Mar 2021 16:01:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 672336B0080 for ; Tue, 30 Mar 2021 16:01:12 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2C708180AD830 for ; Tue, 30 Mar 2021 20:01:12 +0000 (UTC) X-FDA: 77977609584.10.FAA7A51 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf30.hostedemail.com (Postfix) with ESMTP id E460DE0011E2 for ; Tue, 30 Mar 2021 20:01:10 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id u9so21242394ljd.11 for ; Tue, 30 Mar 2021 13:01:11 -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:content-transfer-encoding; bh=iUQpi+sJY96M0oTRItdYRMKHG3+VxUz+t6vY8dGmO+U=; b=oeUZ5mND0ZbBb92my2vpif9MOmzQpXmPHa6ESdE9DoEgmJ+f4n7aaHY2hH2cLOqBU5 lVvw3oI5Hub03dWw0BPaeUYp7WteB8Z+ilsGDG0uvhCNa0btjGOj4iqHeXlIKIh2AqM3 HMOgo3bj2JQddAe6BV9FPcySj7NAFx4dwvGTQHf3a30b44vc8Vpc/9QkLiUDRuMchM0k zrxWJ4f6fkYlf0ube1r+3OFxfH05Nf0v9t/1zeHq26DG7zOuAjK/m1t0GVOiC3DM5hjt iSsfM4b2LKDhF+tTotxIuu8AzYxnN/Tv5JkVaPgMIgPArL+cQSbK9IzJQvEkhuszTrYy FdpA== 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:content-transfer-encoding; bh=iUQpi+sJY96M0oTRItdYRMKHG3+VxUz+t6vY8dGmO+U=; b=slxt6NGGL5VX0NFAS12bL9psHPdYP/jLXO2Y75J9i3jPd62HqRaBQvsX5RF5hQpVwW gTdFgsd2idtz+fnLTP48x12Usnn9J4mkZPus3swxm9d1tihLhrTWdNBfbw6O4YnYmn9K 9XhUzVlYGlvwKpwRHSVn/ZK704qFprBw5oJEiqHh/RAe7NuSo/8KfIV36NTt6tJUjBI0 r5K9DOBXBEa3ACjiylD/+dduHQK4a8bNuZPy7zN3077g112CFwHSmLXcb/ix6oGhTTCX ZEWJzCobAYwrmQ3wepKe9L/G4SymU+RmemL3Pci5UcHQuzWzmJsW0glAH/Llmr/OLo+M hZ2A== X-Gm-Message-State: AOAM531z3U58TEw4lDVftsd3avRKx837zIrypZ8q91zl5wrfJJDMupxt qz2DfMKxXDvt5/lpnVEpq17SSbsFljOttgr/DdPcMA== X-Google-Smtp-Source: ABdhPJz3sX1eTQm5fKKV5RmJJoxAuSmvn4gDPlEJ/96820aGiIae+uwCS6EeIvCfqacZ4jbrc/sDWj9KXHXzdKtgdwI= X-Received: by 2002:a2e:8196:: with SMTP id e22mr22326561ljg.398.1617134470053; Tue, 30 Mar 2021 13:01:10 -0700 (PDT) MIME-Version: 1.0 References: <20210322215823.962758-1-cfijalkovich@google.com> <2E59E29C-E04D-417C-9B2B-7F0F7D5E43EA@fb.com> In-Reply-To: <2E59E29C-E04D-417C-9B2B-7F0F7D5E43EA@fb.com> From: Collin Fijalkovich Date: Tue, 30 Mar 2021 13:00:59 -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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E460DE0011E2 X-Stat-Signature: ci44ffcbz3b17kb58ua5h9gt7a4ckkxz Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=mail-lj1-f179.google.com; client-ip=209.85.208.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617134470-563938 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: There will be an immediate performance hit when the file is opened for write, as its associated pages are removed from the page cache. While the writer is present there will be the usual overhead of using 4kB pages instead of THPs, but there should not be an additional penalty. It is problematic if a file is repeatedly opened for write, as it will need to refault each time. - Collin On Sun, Mar 28, 2021 at 9:45 AM Song Liu wrote: > > > > > On Mar 23, 2021, at 10:13 AM, Collin Fijalkovich wrote: > > > > 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 4= kB pages and block use of THPs. Once all writers complete (i_writecount <= =3D0), the file can fault into THPs again and khugepaged can collapse exist= ing page ranges provided that it can successfully allocate new huge pages. > > Will it be a problem if a slow writer (say a slow scp) writes to the > shared library while the shared library is in use? > > Thanks, > Song > > > > > 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 filesyst= ems, > > > 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 cac= he > > > 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 un= able > > > to apply VM_DENYWRITE through the dynamic linker, preventing them fro= m > > > 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 >