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 67574C4332F for ; Thu, 20 Oct 2022 20:14:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90A188E0002; Thu, 20 Oct 2022 16:14:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 893B18E0001; Thu, 20 Oct 2022 16:14:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75B5A8E0002; Thu, 20 Oct 2022 16:14:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 61C578E0001 for ; Thu, 20 Oct 2022 16:14:19 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 24BF9160707 for ; Thu, 20 Oct 2022 20:14:19 +0000 (UTC) X-FDA: 80042429838.08.ACEE57B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id E16894001C for ; Thu, 20 Oct 2022 20:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=yBeapEUyqnEGwhHxvNgNiqxl+O4YFIghDqN0jhek1g4=; b=VWDhhwOhEZFj9dSpujQzfcRYeC Rk1PNBwNZ+PfPUYZS1xUZ9vWgFZ7+Y2O5NvoRdfFSiUo3X+YgQQFsiVThrQWA9XpfMPD9iUtjPljo wo9GOjoa4ftQD7EmZPQHIC/RcijN5xsFPW551juHgwZi7w+VsjKxmJm3tw1V1FKwpwELm0NYgqGSD WWzG7bTxi962kuhfiHUwXNnOp7kMYiIR9K7iis1sHlSwrilDB/4UwLM47PfZ6P+beuCadD1sVrkMy kUP5JDWBgTmt/9W2ydRahdFItfqQGi6YsLRbi5toRP5gA5hOClqY6hrnWO6GJ7ItDnPiTQJzMvxhp 9SFH8Sgg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1olbvd-00CdoL-4Y; Thu, 20 Oct 2022 20:14:09 +0000 Date: Thu, 20 Oct 2022 21:14:09 +0100 From: Matthew Wilcox To: linux-mm@kvack.org Cc: Hugh Dickins , David Hildenbrand Subject: Avoiding allocation of unused shmem page Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666296858; a=rsa-sha256; cv=none; b=ufTlZL9MUzQtZTVftbyNyfBuMr35nuR5qDC8hPi2bic8p8savAv1kKFDSLkQBEWKgeiOnN 2IPLWfq6+ibB4pkRYKBtfETF4T7htLDPBu7AkGjBY6ZNOMGOSu8QMSN74WA7obbL7Lvv0B DWGSOTaqxZl/vJLIZ1nf9sOKwyHaIo8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VWDhhwOh; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666296858; 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: references:dkim-signature; bh=yBeapEUyqnEGwhHxvNgNiqxl+O4YFIghDqN0jhek1g4=; b=WmsngeY1LEH2g0d0WZ8kDeGf1WkYQfaqZDnhU2qU4/nEKeQpt1TmcFWZ1IzRSj1E/LG88e tRyjKYWvxi/PYmOdKYj1klA+MsAHQXk3EswuamP+CPJogsDUj7PHD5YP67wI1gSt91lbH6 vhFbElwAhlnWiypDYpFq+plpwJHGIcg= X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VWDhhwOh; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: wj1fih559s7tyb5xex8q8dojsqq3yxaa X-Rspamd-Queue-Id: E16894001C X-Rspamd-Server: rspam10 X-HE-Tag: 1666296855-455631 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: 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?