From patchwork Tue Jul 21 09:12:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 11675245 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9ED46138C for ; Tue, 21 Jul 2020 09:13:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6C1A420792 for ; Tue, 21 Jul 2020 09:13:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XTPSeWfa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C1A420792 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 676476B0005; Tue, 21 Jul 2020 05:13:06 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 628296B0006; Tue, 21 Jul 2020 05:13:06 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EEC16B0007; Tue, 21 Jul 2020 05:13:06 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 35DBB6B0005 for ; Tue, 21 Jul 2020 05:13:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BD96B182CA8C6 for ; Tue, 21 Jul 2020 09:13:05 +0000 (UTC) X-FDA: 77061518730.15.uncle89_4701d3326f2c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 8F97118249354 for ; Tue, 21 Jul 2020 09:13:05 +0000 (UTC) X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,mpatocka@redhat.com,,RULES_HIT:30054:30056,0,RBL:207.211.31.81:@redhat.com:.lbl8.mailshell.net-62.18.0.100 66.10.201.10;04yf34jf6kdwocswruzbsriod4o1dyp3ny686f77661dgxksan5ea1inmtzc6uq.fc5ctrzww17b3umh1eu7wketohoipou534qcx36j7eshddbqwnqrmkjuugdpobi.r-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:ft,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:33,LUA_SUMMARY:none X-HE-Tag: uncle89_4701d3326f2c X-Filterd-Recvd-Size: 4411 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Jul 2020 09:13:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595322784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=noXi7Dzc6YiFbpAgK1bY5KdvqlDBTqYvm5sWJw58cd8=; b=XTPSeWfa2DjHJddjEZBqR9XKvy71Ci9+/LcfdW96MZVl4HPX76ntWDQ/GQEpD4RMDDjh2M fs299Q96vrncxl1VZq/GdtL0BUU2+AvJ7cSAXkOnSgFkrDBtZ9/tbAh37QcQLLYo5ToDoq LKYuWwT5VN2qDE5lEaVKpbVZYZaFUns= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-325-fii8OQbkNRiZitXlVBwqTQ-1; Tue, 21 Jul 2020 05:12:59 -0400 X-MC-Unique: fii8OQbkNRiZitXlVBwqTQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DB40A1902EA1; Tue, 21 Jul 2020 09:12:58 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9085A72AC6; Tue, 21 Jul 2020 09:12:55 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 06L9CtqV007057; Tue, 21 Jul 2020 05:12:55 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 06L9CsdG007049; Tue, 21 Jul 2020 05:12:54 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Tue, 21 Jul 2020 05:12:54 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Hugh Dickins cc: Zdenek Kabelac , linux-mm@kvack.org, dm-devel@redhat.com Subject: [PATCH] shmfs: don't allocate pages on read Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Rspamd-Queue-Id: 8F97118249354 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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: Hi Do we still need the patch a0ee5ec520ede? We are using the loop device for testing and when we read something from the loop device, it allocates the pages on the underlying shmfs filesystem. See this example: # mkdir -p /mnt/test # mount -t tmpfs /dev/null /mnt/test # cd /mnt/test # truncate -s 1GiB file # du -hs file 0 file # losetup /dev/loop0 file # du -hs file 1,1M file # dd if=/dev/loop0 of=/dev/null 2097152+0 záznamů přečteno 2097152+0 záznamů zapsáno 1073741824 bajtů (1,1 GB, 1,0 GiB) zkopírováno, 4,06865 s, 264 MB/s # du -hs file 1,0G file This patch turns off the allocation on read. Signed-off-by: Mikulas Patocka --- mm/shmem.c | 8 -------- 1 file changed, 8 deletions(-) Index: linux-2.6/mm/shmem.c =================================================================== --- linux-2.6.orig/mm/shmem.c 2020-06-29 14:50:06.000000000 +0200 +++ linux-2.6/mm/shmem.c 2020-07-16 19:22:58.000000000 +0200 @@ -2507,14 +2507,6 @@ static ssize_t shmem_file_read_iter(stru ssize_t retval = 0; loff_t *ppos = &iocb->ki_pos; - /* - * Might this read be for a stacking filesystem? Then when reading - * holes of a sparse file, we actually need to allocate those pages, - * and even mark them dirty, so it cannot exceed the max_blocks limit. - */ - if (!iter_is_iovec(to)) - sgp = SGP_CACHE; - index = *ppos >> PAGE_SHIFT; offset = *ppos & ~PAGE_MASK;