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 A07AAC433FE for ; Thu, 20 Oct 2022 22:17:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41A218E0002; Thu, 20 Oct 2022 18:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CA558E0001; Thu, 20 Oct 2022 18:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 291F48E0002; Thu, 20 Oct 2022 18:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 148388E0001 for ; Thu, 20 Oct 2022 18:17:37 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D3217ABBF0 for ; Thu, 20 Oct 2022 22:17:36 +0000 (UTC) X-FDA: 80042740512.20.D99B37D Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf22.hostedemail.com (Postfix) with ESMTP id 7C8B2C0033 for ; Thu, 20 Oct 2022 22:17:36 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id d24so600902pls.4 for ; Thu, 20 Oct 2022 15:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s8QrGE1AO5eEdDAYsPdrZ9z6pYU5BHGbL+NNdJ+p+zk=; b=qNfqUu6Ll5DJU3As9x64VpZouRg2drSGvF+r5eD/N7PEpfag0GpnMccA/pF7SqiNqO o67WnBrWX3pby+yNZqgverab/EC3I405CKQ6Gp7lgXTkhCHUu/ul1P4LZjaZc224szte YngQPU/o3fWbYRl98MAYEAjsgGy5gGP2fNN/pKns7ygp62CMKNCETUVmmoLpiLiUyKt+ XmEMeGnEl9fdtlDNYVAey5cTDWjSQRyqYWNHwOQubkedP4kg2WuV1eW6puXPXsDz2LbX Z/TvLX04SpJvJ6Lncq8XIQ1YxRK9DP0OYX7zWdSQ4EaKucgW1332RUPL3me2OMWoprYM 5SZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s8QrGE1AO5eEdDAYsPdrZ9z6pYU5BHGbL+NNdJ+p+zk=; b=l/iH2aGDiFJe+vT3jMHyrc7o6cU2zKLFAA1xrqmHmEbnFsn1OepJXVqFfdQCsuNQnJ l0b6au9/JW8YMoqPjxAW+6g7DoqKzVLf/DU54rPS2VoVysR8Q6Sy5XN94cQVhGGW/Ou6 L25BMjgaWeRUnRok77YCOqhe3mXTjT9cUg8i9RjWFGXs63jzNb7Xbbjx8SnwsGSBwaBK PJ5JyMbuwrlYSD/i9KfCujhh+lhcrYdmtVu0pW/VFfa0J2FvFGow+fc1mOElrkkuNl9o lwjVzlBzeebQsjP/iZwWscQR3rdm7uAbEpdrmaIcvzvH3aOJuSGw8Gh/NhByyFsMyc5n CS/w== X-Gm-Message-State: ACrzQf05+eZXgaBMwzHaxb7tHqInmtvgnCYxT3/238NAEbo2QcKFc1vk OaJLO1qOoPuYbzbg8fMQcHav+sIDlTU3MnjvFxU= X-Google-Smtp-Source: AMsMyM6y4Ed+415A/BSXNuGcNPQa0grUfacdnY2sPhLjPB/K5f+vV0C/+fJSoX1nMpaCNPrl+reqf63K8bpDdLMejz8= X-Received: by 2002:a17:90b:1c87:b0:20a:e485:4e21 with SMTP id oo7-20020a17090b1c8700b0020ae4854e21mr18377157pjb.194.1666304255278; Thu, 20 Oct 2022 15:17:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Thu, 20 Oct 2022 15:17:22 -0700 Message-ID: Subject: Re: Avoiding allocation of unused shmem page To: Matthew Wilcox Cc: linux-mm@kvack.org, Hugh Dickins , David Hildenbrand Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666304256; a=rsa-sha256; cv=none; b=is388DYWqMnxbl5htzmRrQEJxQ+sLoRzUI4WaoBqcECnaI+ZQEsqm64q6v+B4Beahc8NBb cgYYwu6y8DdXS0PxT4ThpNxOdzTqkUxc8uZbaOuyyGdQSwW/0XSWank+HMuGQCoxoPwhYr WgrgfbNavSUceMzQIVzDz3mW0fxadcc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qNfqUu6L; spf=pass (imf22.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666304256; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s8QrGE1AO5eEdDAYsPdrZ9z6pYU5BHGbL+NNdJ+p+zk=; b=yvgQwzcDFbjPfzvdVadb9lBZrsu2Lu3MuoLP/ImT8RouCcS42T984BaRH7LokLI/lnnhlw FoeBnq8woJc3aV5ypmPoTDeAp8YjT+sqD/l0wJ5ztpCvQrDzQtC3tVsvpr41HznJP9h4VY 3sCUtHqd+mG4cEXz8sPvV3zLNm25Cyg= X-Stat-Signature: xmndre5m16cgewy64tuwr33eq5bp1i5s X-Rspamd-Queue-Id: 7C8B2C0033 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qNfqUu6L; spf=pass (imf22.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1666304256-170788 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, Oct 20, 2022 at 1:14 PM Matthew Wilcox wrote: > > In yesterday's call, David brought up the case where we fallocate a file > in shmem, call mmap(MAP_PRIVATE) and then store to a page which is over > a hole. That currently causes shmem to allocate a page, zero-fill it, > then COW it, resulting in two pages being allocated when only the > COW page really needs to be allocated. > > The path we currently take through the MM when we take the page fault > looks like this (correct me if I'm wrong ...): > > handle_mm_fault() > __handle_mm_fault() > handle_pte_fault() > do_fault() > do_cow_fault() > __do_fault() > vm_ops->fault() > > ... which is where we come into shmem_fault(). Apart from the > horrendous hole-punch handling case, shmem_fault() is quite simple: > > err = shmem_get_folio_gfp(inode, vmf->pgoff, &folio, SGP_CACHE, > gfp, vma, vmf, &ret); > if (err) > return vmf_error(err); > vmf->page = folio_file_page(folio, vmf->pgoff); > return ret; > > What we could do here is detect this case. Something like: > > enum sgp_type sgp = SGP_CACHE; > > if ((vmf->flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) > sgp = SGP_READ; > err = shmem_get_folio_gfp(inode, vmf->pgoff, &folio, sgp, gfp, > vma, vmf, &ret); > if (err) > return vmf_error(err); > if (folio) > vmf->page = folio_file_page(folio, vmf->pgoff); > else > vmf->page = NULL; > return ret; > > and change do_cow_fault() like this: > > +++ b/mm/memory.c > @@ -4575,12 +4575,17 @@ static vm_fault_t do_cow_fault(struct vm_fault *vmf) > if (ret & VM_FAULT_DONE_COW) > return ret; > > - copy_user_highpage(vmf->cow_page, vmf->page, vmf->address, vma); > + if (vmf->page) > + copy_user_highpage(vmf->cow_page, vmf->page, vmf->address, vma); > + else > + clear_user_highpage(vmf->cow_page, vmf->address); > __SetPageUptodate(vmf->cow_page); > > ret |= finish_fault(vmf); > - unlock_page(vmf->page); > - put_page(vmf->page); > + if (vmf->page) { > + unlock_page(vmf->page); > + put_page(vmf->page); > + } > if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY))) > goto uncharge_out; > return ret; > > ... I wrote the code directly in my email client; definitely not > compile-tested. But if this situation is causing a real problem for > someone, this would be a quick fix for them. > > Is this a real problem or just intellectual curiosity? Also, does > this need support for THPs being created directly, or is khugepaged > fixing it up afterwards good enough? AFAIK, THP is not supported for private mapping. >