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 EAE74C41535 for ; Fri, 22 Dec 2023 08:23:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 722EB6B006E; Fri, 22 Dec 2023 03:23:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D3CA6B0082; Fri, 22 Dec 2023 03:23:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59B046B0087; Fri, 22 Dec 2023 03:23:33 -0500 (EST) 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 45C026B006E for ; Fri, 22 Dec 2023 03:23:33 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 237201A0646 for ; Fri, 22 Dec 2023 08:23:33 +0000 (UTC) X-FDA: 81593765106.27.1C96617 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf29.hostedemail.com (Postfix) with ESMTP id 0B9D512000D for ; Fri, 22 Dec 2023 08:23:30 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=Z21yqyJ2; dmarc=none; spf=pass (imf29.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=slava@dubeyko.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703233411; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NFPcAgqpMDjUyOI46eez858frmAfzDRXlIM6U59hUac=; b=lD1GuX++75bUb7nQhKcB+0ohTnYqPVXsoLIH2bRaukC25UaJBAWeX8QGi5ELO/JjclOxdO 9jOu1SEql9ctrS8qPnKmIJa4SirHSOqmR/HbWGMlBxPDJyOm08b3NSaRxpL5ffOPsQH381 pkIsdVHvxppIwqV5v9Er4v6Z0QQjqG0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=Z21yqyJ2; dmarc=none; spf=pass (imf29.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=slava@dubeyko.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703233411; a=rsa-sha256; cv=none; b=nNvQtuFVr7Ozr6Eb2TTyyZbNjeb4blm/x6NRM/WobosrBEBV1BMyWccWnipG7tuu5tMKqF 1ScXSg0fZ7jkJ9xS8wKi5VqgANvJ0mNKlpW+hJYQWN4I/9YhkAb23DCQHdDqrYwCfHAIgQ qzTW85lEfQgdjXEfE1x4B1T97Vv/fEU= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2cc7ba7d12eso17314961fa.3 for ; Fri, 22 Dec 2023 00:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20230601.gappssmtp.com; s=20230601; t=1703233409; x=1703838209; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NFPcAgqpMDjUyOI46eez858frmAfzDRXlIM6U59hUac=; b=Z21yqyJ20QlmT9zdxurRqurHkBl8joUfagJzeUlSTWJBTj47kzJYIdsIOAjPo5/qPB S7LGoeztqw9uDVzH9JjNtTnGjBm8W4pA8y+AhjHycDNJTQoCUJngEm/NjZ1ZuW3K111v /M+ArFdQXS30L0SnJS8KeQV8AOmCTUsHypk4Wy+3kcB2bQ6HbehDWX8pS3uoED7jTXie Io3rdgXTBu66OQq6IFiKkVBD3RCj543NaClWBScMKKhttOpVpKbfialM7ZG1iYRH8Osa 7cqMCtmfrx2ma6CrznehUGfCUwrdYI9nHFyE2Cjh0xYSN7UxzAJgtfjyW/5qpvv8mMby 9wFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703233409; x=1703838209; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NFPcAgqpMDjUyOI46eez858frmAfzDRXlIM6U59hUac=; b=qCrVrF6tfVIL00K0Xl927uO0PWNZXf9yaSuP5aSZhrUH2oBKTpIUblqVn5tDCIdJmc uTFihBb/hjjpttcJ9JFLVQupUIJCBs4GNcFQM+5arhiMIshmnqEd1KDyMREi2iZE7tWX jORGX53PN1k3pH/pgwW8ERNBMEVhjH7UDtwh4ajhyUQGJwqmJX70NcYfhVpXZbs2S8bm eq3Amr7TUXYkw3P+JxC6h8DRTpm2ryUbZmIc4HsFjcGTHeDDzKaEA+OosCG2njMoWzOK 6i/iwarvlDVh7UJYArokJKluTLtWY+XdZkEwyukj6VatAW/1Lfjc0tN9LTjzp/VTWeym ccoA== X-Gm-Message-State: AOJu0YyhWpJExn16p34z6s9YE5ZQjVJPFcBWW2I1hp8+fnf+hGDj3YX4 Lv09XhtlKurVjLQUkG9Yg1Mt6G1jNHWSjQ== X-Google-Smtp-Source: AGHT+IFkscMU1YqM9TeOxdQwwPdMY0LVyQ1RQr8PJCjzUZLPSRsA6j10f2Q7drwwodCNnYizhoi1VA== X-Received: by 2002:a05:651c:119a:b0:2cc:7147:c8d8 with SMTP id w26-20020a05651c119a00b002cc7147c8d8mr222602ljo.65.1703233408967; Fri, 22 Dec 2023 00:23:28 -0800 (PST) Received: from smtpclient.apple ([2a00:1370:81a4:169c:118e:db44:e99d:a2b]) by smtp.gmail.com with ESMTPSA id r10-20020a2e994a000000b002c9ef016247sm533540ljj.132.2023.12.22.00.23.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2023 00:23:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [LSF/MM/BPF TOPIC] Large block for I/O From: Viacheslav Dubeyko In-Reply-To: <5c356222-fe9e-41b0-b7fe-218fbcde4573@acm.org> Date: Fri, 22 Dec 2023 11:23:26 +0300 Cc: Hannes Reinecke , lsf-pc@lists.linuxfoundation.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, "linux-nvme@lists.infradead.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7970ad75-ca6a-34b9-43ea-c6f67fe6eae6@iogearbox.net> <4343d07b-b1b2-d43b-c201-a48e89145e5c@iogearbox.net> <03ebbc5f-2ff5-4f3c-8c5b-544413c55257@suse.de> <5c356222-fe9e-41b0-b7fe-218fbcde4573@acm.org> To: Bart Van Assche X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Rspamd-Queue-Id: 0B9D512000D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: za9fcuiyzrsuzp6urbqe11j8e3oj6p1n X-HE-Tag: 1703233410-245830 X-HE-Meta: U2FsdGVkX18wga5jVeQaMKpAqTszLOROeA3NnayDep1X2rsy9y1YsB/U1Cxg32Tp4mkv89x3cU5JoYAhpzVe4NkDFAwsh3P3x5E09pvI2EjWN+0RoWuYNk698tvfqoVKEHo+Cule4yezTmQdr7WjSgF6MoJHcX4d3eCVFD+uzuWN3MHuClwTZEr46NShxlSNI9gYZ70PbSzRg6G2Va8206Zno4H2vhatOzChaqjn59WUbpIzRrCMLuO+W69SC+VEakuuGN+yHRpQQSLYs3b7wba2SeoykqPKdvPDH8BhK39F5529TtmneeTtRMDOq/Ddi2LaQQC2+AbyxIhmiga5nayG8eqNzVTbFdLcgaP5pkfDZITfmbIowOIX9pnsW4Tz5lkFGY8xCt1cejprFMMD75eFasL2HkjZCcyAMGgx+djrA1CtzAagPpXaX020ezlz77K3+ADzBDsSl9SXlSjshp/+kCZtfiPpWA9W0W1wIzpSVvZ59oaU4sm4NqU3tvgoKoeFNlSsuA3JnXoftD0bGOA1Dg3i5srlCHO9uW9Ybw0jIoUdw/ntDQQ+gDutJKkLqp+mrvNQWPgfWYA8mw6wHKJz6XADaAagt/Tgy+T/X07aqntpC+nkjl0gMOtvxO/+zVstBuxtrzlGv047DdGEaqzKzR9Bem9HQG+HMcxSNxSlgX8cgarvomWgnCOVRu5t31SfcsJ7qUdDMNSZM3WCsWgAp7/OSoSnB6V2NDCvFiZBMz5P3FxTBLkFM9aWsXcjMLAnWR69ch4TuWopKC3hxdKz1STPYnVuQzrqT3W/H7rqIxIRxpO7ZJF3wWgTxQzE1Kgh9B4BX24GY5J+ar0hmwhdnaDXeDhk8Y5hZxxj5u9wLBr34crWEU7IULhiltMCFRjZXkIdLgIxtmsZGMskzaMxUWJQg0FXFoQsbUFCBw+AeP3zAA2iWv8DFhwoDTVj4IWWPcA5w9T1N47iZPq GDl+buJQ 6yBvDQ/gQKyBhV18huhZd6a3bxaQ5G4nf/ycD4DIBtVow0UgdVlW3GHc576aRBgE99C18P2OnyEUr/0Q3x4DmgOS6V7ZEMOZ7EhUtKafVlgL645RkB4UCkfGc1/Ed9ilf1G5UaDuHIacj2CCW1XbeVwaK2FoqC4co98JP7vwdLNAEMOU2vEoWMMsplbjhlb8SZ3i8N49pe+5QaUReUm4RilhcfLZ4E8tOZ0SbIW11AS2PIADBwLwlQGSh/SFNjMNNTsqLN3sql3e9P9nIGBAi5jNyQoq6HpU+pe51sB/8NESYNeE2j64vIxxdDTJTc2YAyObFHk63gZezlIAfZtqXI2aEef7hhGsaIZU4sWPzBwDwDVf2VbYvLW71O0FT9fXeoHZViT6XoWLpuB3N58v3R33OfIeDKGI39w1c8vo6uPtjSBA74glJPFJymtG1xG8KdtfNCBJb9RlCR55Ra/9UvQTecAgfIJvMLvxRsIdyaCT3eB5OY2ikJtKzKlDV+prnBabGqjVvPYtpK6Yt/mVSFWKiSA7bP8cmu1wciM1wz3foRcfRzqYG3VYn3aHgz7buYrcCrUhMNj8mNmKjvaaHcigdcJJX8dHvqKnmH4opuesql2EAQiI+D1ZBJIUh+ByM46kleyn1DN8Erg4CkJ0QmgKpm6dvdmbuOSIBBz8s+0BJ0WRgw0oQHY1FHg== 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: List-Subscribe: List-Unsubscribe: > On Dec 21, 2023, at 11:33 PM, Bart Van Assche = wrote: >=20 >> . >=20 > Hi Hannes, >=20 > I'm interested in this topic. But I'm wondering whether the = disadvantages of > large blocks will be covered? Some NAND storage vendors are less than > enthusiast about increasing the logical block size beyond 4 KiB = because it > increases the size of many writes to the device and hence increases = write > amplification. >=20 I am also interested in this discussion. Every SSD manufacturer = carefully hides the details of architecture and FTL=E2=80=99s behavior. I believe that = switching on bigger logical size (like 8KB, 16KB, etc) could be even better for SSD's = internal mapping scheme and erase blocks management. I assume that it could require = significant reworking the firmware and, potentially, ASIC logic. This could be the = main pain for SSD manufactures. Frankly speaking, I don=E2=80=99t see the direct = relation between increasing logical block size and increasing write amplification. If you = have 16KB logical block size on SSD side and file system will continue to use 4KB = logical block size, then, yes, I can see the problem. But if file system manages = the space in 16KB logical blocks and carefully issue the I/O requests of proper = size, then everything should be good. Again, FTL is simply trying to write logical = blocks into erase block. And we have, for example, 8MB erase block, then mapping and = writing 16KB logical blocks looks like more beneficial operation compared with = 4KB logical block. So, I see more troubles on file systems side to support bigger logical = size. For example, we discussed the 8KB folio size support recently. Matthew already shared = the patch for supporting 8KB folio size, but everything should be carefully = tested. Also, I experienced the issue with read ahead logic. For example, if I format my file system = volume with 32KB logical block, then read ahead logic returns to me 16KB folios that was = slightly surprising to me. So, I assume we can find a lot of potential issues on file = systems side for bigger logical size from the point of view of efficiency of metadata and user = data operations. Also, high-loaded systems could have fragmented memory that could make = the memory allocation more tricky operation. I mean here that it could be not easy = to allocate one big folio. Log-structured file systems can easily aligned write I/O requests = for bigger logical size. But in-place update file systems can increase write amplification = for bigger logical size because of necessity to flush bigger portion of data for small = modification. However, FTL can use delta-encoding and smart logic of compaction several logical = blocks into one NAND flash page. And, by the way, NAND flash page usually is bigger = than 4KB. Thanks, Slava.