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 E0AF6CE79AD for ; Tue, 19 Sep 2023 21:47:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6014F6B00DF; Tue, 19 Sep 2023 17:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B0EA6B00E0; Tue, 19 Sep 2023 17:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 454436B00E1; Tue, 19 Sep 2023 17:47:09 -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 358D16B00DF for ; Tue, 19 Sep 2023 17:47:09 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F118C140E02 for ; Tue, 19 Sep 2023 21:47:08 +0000 (UTC) X-FDA: 81254682936.23.EB80C15 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf15.hostedemail.com (Postfix) with ESMTP id 49EA7A0035 for ; Tue, 19 Sep 2023 21:47:06 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=xsrTNQVm; spf=none (imf15.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695160026; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OfltgZCqgs8MKY2Ik0pJznlTGh3QDwezyPAsC9bskLQ=; b=SLC/qgZuSYAIGkAZiFzzlX4CNY3K8gb7JkimxIm5T6Tu+28ZEdePawATeUq9gbg0I6pFix rQwdY5kJFH+Z4i4bkkgMfycnpYcPe3/WvaT9IJLVdfFL+G7fj6eyi6nzhQFN5CPgcWgAg+ 2G2t3M0DC0xZEaSjtVJKfXbEjI1zNsE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695160026; a=rsa-sha256; cv=none; b=ucMObCuUUF0rs87OHKHDHQXBhcXBxCiiiHnXE2F73H3PE96Nkn8roeWvNd1uadpT67Zcse vqhKFUbqJdninocF7teexvFn3CrL+lz26llNrlAG5UGL+A/1cQxpaiH3s+M69Tr+001olI VHqfb/Dspp8v9DuSeOlkT3jhHZfw0G8= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=xsrTNQVm; spf=none (imf15.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=OfltgZCqgs8MKY2Ik0pJznlTGh3QDwezyPAsC9bskLQ=; b=xsrTNQVmaeNsIPIzTh1iJZjUz7 KSqGhVEa2eNcD844y8hm2Z3XmYuAkDfXQWVQzeGLrJw557n4LSqw20j3ZrFmns8vy08xNfzVB0+Vi BkWPLTuncAFG9kaViqJsh8FZJakIObIs4wghKYHz7ivOO2WxkNCo/9uScME0+/lIsjZimhmX5TrUJ jByErSGcdhV5yKGRqn1zT6UcKmeo5rDg5hrLXhJ27G+5DCdio/JZkz/qbHlXImp5ElHChquGZRFgc pSLaR1CYouOPBcIKM5UA2zI4MOH3G4XtjbthpMoJLTFFdLyHcTeF21Ey4xH/3PZ1i9gpcoDu6qIOM ROzU472A==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1qiiYa-001JIQ-0d; Tue, 19 Sep 2023 21:46:56 +0000 Date: Tue, 19 Sep 2023 14:46:56 -0700 From: Luis Chamberlain To: Yosry Ahmed Cc: Daniel Gomez , "minchan@kernel.org" , "senozhatsky@chromium.org" , "axboe@kernel.dk" , "djwong@kernel.org" , "willy@infradead.org" , "hughd@google.com" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "gost.dev@samsung.com" , Pankaj Raghav Subject: Re: [PATCH 6/6] shmem: add large folios support to the write path Message-ID: References: <20230915095042.1320180-1-da.gomez@samsung.com> <20230915095042.1320180-7-da.gomez@samsung.com> <20230918075758.vlufrhq22es2dhuu@sarkhan> <20230919132633.v2mvuaxp2w76zoed@sarkhan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 49EA7A0035 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: eo11xjh8j34oiu6z4w68b5w999ecaw9f X-HE-Tag: 1695160026-134805 X-HE-Meta: U2FsdGVkX195wwdC5F1WGaOh2PnaDO+MbiQo2yEQe1IgGOkwFuWlEJh9XXfT2+SMjqDv4oWGEd8qnBG9FrSSEqDN/OQFFF/W0zeY+5RZ1q/s8K5JFSP/Vpbhc9jJvqDT/G3QGWMiU8cFu1UpQM0GSz72zZf0TP2fv0H9pLa90G58EVpezpVB2gZU4IXYmrFKOY0jEb2N3I9duw2ezINS+NA0qbsvGaw48wfygcL49yNIA3NeVIzQRQGJFa4GRc6aMY0gyeET0CG6TYn12utSUer31L3LF7Pr7IJjuUUxrVBacL6FaeCCUe1Kj9owob+lgWlYaY8KcuSeCCvYbgINNsPsaZLnS3fZ2zQTKL1k6rsvA75KwyfKBiWGwvKvgJ0BgAg5/ICHE5uZD15JmSOMqVIhuy5pgfpsAOJBpg7VTBX0I2yq9jaQ5a1aHPHtK5+DeYiK9N7DNaHCTSr+kA1xDZyC46vQHcqd49FUHRGSsnDBBeytOGsQap1C+FqjnB9JB2/mLAjowi0TvSjw3lLLzzUHjw5DU3EyRDwnSS582EFh8zqap+rKeQD8ldKs5Kd28CNnCplUggj01clwwg0w3YCaB4vCd19zsgdk1KmJuC2dRQ6NMo40fd1n1SN3bcKh16IlSNbo/Iv9EOKcT//lyncJwkaaIiQbwRpTHnbJ0ur+WzP5cEkI429EvfaEwdZeEt6zL3/7xAI1Oaetgo8a3qc2A4tEQ1P4WNR6JO3jT/HbKoSXjSOoUHSBxX45w1eWY45k5Fq4rsdbyoR0MxODzXqMQSP+BBw8IzoNZawQY36JJ91OLhOGK1ZzXCAocy3cDKTrMJhJvvVJvgh8lbgk+fzhP9M+1mXbkYpMzfSPp+Zl/L9Uz/C+O3zlO2TPr/2Czb1d4t75XLPLU2CUifUiwbcBQk+giKe/eudbwnYdtplEzRaE8sOu54fyHwOxHiCYK4NoyOqxDNXM9VateOh BX9tf4w0 0s/+qn5VsGRIIt9CHFlLguPLFoADtZSSMUWf9cJI80wMIzUuwKPcU/CnUJt+5n+KxLTROB8kjrlZ/wuBIwC/DZBv6e7Zd5NxDRzdzHCJ+EBmQuhe1eS/uivCUGMOvDtppPTqVulMm44EMPMgR94UVg3aFY70F/BYa+nfnIjUWsuMevpq6hgw0ILtEaURb53kJcWQZ3EMg1UwxSoUfoFmS6LZ1NUswZGTWbNTIwYMQdIiyLrbRJ07dgG90MOzqvVh1KBk6yiTJnfcNoMldLSI9ZFXs+fKV/nvixzxT4FSCw1Yu6LREZgojn09d5/fFJ8M2qZ9bmDOrZpZxa5qMnhQu4PWEo0ZmmRDdE+e0dhLrkh0hQVaP9+nWyZlJUAM3JOb3EojnEt8aDdk9daC5gZz3m5rdwgdyaV0aRqC1n+mvkgUjPfKbAObird5JeQPD98uIiMx50jTHB/QJNerAcGMhfOrcX4Fu9It6mrPElP0UDklhdSEvFefIUqwV59SyGgHUNjID/OXXUYspE2mPYYuM5Alu5Gx5INmQEsx6DpkrSTIgM07AmLfKu0dd7AhyyTbRRxJ/kdTEO5hcPTNqEaGZFMtlkw== 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 Tue, Sep 19, 2023 at 09:00:16AM -0700, Yosry Ahmed wrote: > On Tue, Sep 19, 2023 at 6:27 AM Daniel Gomez wrote: > > > > On Mon, Sep 18, 2023 at 11:55:34AM -0700, Yosry Ahmed wrote: > > > On Mon, Sep 18, 2023 at 1:00 AM Daniel Gomez wrote: > > > > > > > > On Fri, Sep 15, 2023 at 11:26:37AM -0700, Yosry Ahmed wrote: > > > > > On Fri, Sep 15, 2023 at 2:51 AM Daniel Gomez wrote: > > > > > > > > > > > > Add large folio support for shmem write path matching the same high > > > > > > order preference mechanism used for iomap buffered IO path as used in > > > > > > __filemap_get_folio(). > > > > > > > > > > > > Use the __folio_get_max_order to get a hint for the order of the folio > > > > > > based on file size which takes care of the mapping requirements. > > > > > > > > > > > > Swap does not support high order folios for now, so make it order 0 in > > > > > > case swap is enabled. > > > > > > > > > > I didn't take a close look at the series, but I am not sure I > > > > > understand the rationale here. Reclaim will split high order shmem > > > > > folios anyway, right? > > > > > > > > For context, this is part of the enablement of large block sizes (LBS) > > > > effort [1][2][3], so the assumption here is that the kernel will > > > > reclaim memory with the same (large) block sizes that were written to > > > > the device. > > > > > > > > I'll add more context in the V2. > > > > > > > > [1] https://protect2.fireeye.com/v1/url?k=a80aab33-c981be05-a80b207c-000babff9b5d-b656d8860b04562f&q=1&e=46666acf-d70d-4e8d-8d00-b027808ae400&u=https%3A%2F%2Fkernelnewbies.org%2FKernelProjects%2Flarge-block-size > > > > [2] https://protect2.fireeye.com/v1/url?k=3f753ca2-5efe2994-3f74b7ed-000babff9b5d-e678f885471555e3&q=1&e=46666acf-d70d-4e8d-8d00-b027808ae400&u=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2Fe%2F2PACX-1vS7sQfw90S00l2rfOKm83Jlg0px8KxMQE4HHp_DKRGbAGcAV-xu6LITHBEc4xzVh9wLH6WM2lR0cZS8%2Fpubhtml%23 > > > > [3] https://lore.kernel.org/all/ZQfbHloBUpDh+zCg@dread.disaster.area/ > > > > > > > > > > It seems like we only enable high order folios if the "noswap" mount > > > > > option is used, which is fairly recent. I doubt it is widely used. > > > > > > > > For now, I skipped the swap path as it currently lacks support for > > > > high order folios. But I'm currently looking into it as part of the LBS > > > > effort (please check spreadsheet at [2] for that). > > > > > > Thanks for the context, but I am not sure I understand. > > > > > > IIUC we are skipping allocating large folios in shmem if swap is > > > enabled in this patch. Swap does not support swapping out large folios > > > as a whole (except THPs), but page reclaim will split those large > > > folios and swap them out as order-0 pages anyway. So I am not sure I > > > understand why we need to skip allocating large folios if swap is > > > enabled. > > > > I lifted noswap condition and retested it again on top of 230918 and > > there is some regression. So, based on the results I guess the initial > > requirement may be the way to go. But what do you think? > > > > Here the logs: > > * shmem-large-folios-swap: https://gitlab.com/-/snippets/3600360 > > * shmem-baseline-swap : https://gitlab.com/-/snippets/3600362 > > > > -Failures: generic/080 generic/126 generic/193 generic/633 generic/689 > > -Failed 5 of 730 tests > > \ No newline at end of file > > +Failures: generic/080 generic/103 generic/126 generic/193 generic/285 generic/436 generic/619 generic/633 generic/689 > > +Failed 9 of 730 tests > > \ No newline at end of file > > > > > I am not really familiar with these tests so I cannot really tell > what's going on. I can see "swapfiles are not supported" in the logs > though, so it seems like we are seeing extra failures by just lifting > "noswap" even without actually swapping. I am curious if this is just > hiding a different issue, I would at least try to understand what's > happening. > > Anyway, I don't have enough context here to be useful. I was just > making an observation about reclaim splitting shmem folios to swap > them out as order-0 pages, and asking why this is needed based on > that. I will leave it up to you and the reviewers to decide if there's > anything interesting here. The tests which are failing seem be related to permissions, I could not immediate decipher why, because as you suggest we'd just be doing the silly thing of splitting large folios on writepage. I'd prefer we don't require swap until those regressions would be fixed. Note that part of the rationale to enable this work is to eventually also extend swap code to support large order folios, so it is not like this would be left as-is. It is just that it may take time to resolve the kinks with swap. So I'd stick to nowap for now. The above tests also don't stress swap too, and if we do that I would imagine we might see some other undesirable failures. Luis