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 69399C61DA3 for ; Fri, 3 Mar 2023 22:32:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B41996B0074; Fri, 3 Mar 2023 17:32:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF1C86B0075; Fri, 3 Mar 2023 17:32:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E09E6B0078; Fri, 3 Mar 2023 17:32:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 911B86B0074 for ; Fri, 3 Mar 2023 17:32:14 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6D1231C5CFE for ; Fri, 3 Mar 2023 22:32:14 +0000 (UTC) X-FDA: 80529036588.19.B0B9B5B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id BE3F7140010 for ; Fri, 3 Mar 2023 22:32:12 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E9Fdcjb2; spf=pass (imf26.hostedemail.com: domain of kbusch@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kbusch@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677882732; 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=ZVQm3SlVsXMN+5NwM/I0PgB0Y0jMvApTYGRWURYcZok=; b=oavb/uQ4PRJ99WeUpORFvKvjDqRvOpiuLs2bs8Um4ezUQ+ikBbB+WXDHIEWj0Gu3rlzeBp xhZsi0/z8ensUCG8yfD74vkc8bMFKNH06ZdM1RlrCw4rM2tUeUP3jlSQafCpz+fMlzqwA5 Q5Ud8chN8HeCZrkO8McND7iBvp8SVkI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E9Fdcjb2; spf=pass (imf26.hostedemail.com: domain of kbusch@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kbusch@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677882732; a=rsa-sha256; cv=none; b=6xtYyi17ZbIQtoL7eHtSaAii8niJ3z1f2KD6y/bj4nHjSWG6GvxW4+OonRx1qHsLDtAWWM +ej44Sfu1+7HJolMh3lNl2E3b97m/cZpCa6B8KTzh1QRDogyESOrXnk7ul/Qzpma95p940 bFAlmArSycKuyI0/sKZG9UVbov+jGbM= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AADFC61932; Fri, 3 Mar 2023 22:32:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCA80C4339C; Fri, 3 Mar 2023 22:32:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677882731; bh=YWDLkopnUT96f4fUWZwOykPl42+zKxklVApz3+htIkk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E9Fdcjb2ICy24TPzMJ6/8cdDKEO/yOKZMa2yiGLxfswa9Rxe/8PR4dOdbKDmxnyvi CzgounENeQs4j6J20mPNsz75wJ2KnxiOaK4Ut/lNOAaM9FV7pRyxeLndY4bzkl9Qxz YCxXQFBxPwdOLzcU+Shgv97BopfIWbNRiOZFFgVO+UPp90ix2RGYg+rGlFaW91o2aG nB+26y6uCnKObwM31tFXO0++GK3np+tM64m+AqWkSkWRxPrqYyz6u+ayC4UBcPLxQU +fm2O6HAbEl48MAwzy3BlFekFagOMVgk7j+z5z+ZIdb+/yfsUBNN8kC9AYxj1gXtHo m0yfz8AD0Ju/A== Date: Fri, 3 Mar 2023 15:32:08 -0700 From: Keith Busch To: Luis Chamberlain Cc: Matthew Wilcox , Theodore Ts'o , Pankaj Raghav , Daniel Gomez , Javier =?iso-8859-1?Q?Gonz=E1lez?= , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: fwiwhhs9ofagwpxfxximb8uggh1r1duz X-Rspamd-Queue-Id: BE3F7140010 X-HE-Tag: 1677882732-492329 X-HE-Meta: U2FsdGVkX1/MHE2JWT0HyDR8TX3UQZ3m2Nmu6Tu0DDSb3Xsfhw0AgH441VPN8XexJfZW7mQ7XYTQn/PbgbvwmHRakP1w3W9beuJ539CCcSTA23kC8xOb2zKToLlXlQcCMocy7uvCqAlsYqjT3ph5im/H4E2ZC+zTGTol4/maHEd4V9Wwhhxlge7QZz5/NUPojt0Y/FSiz2zWS+Vj7pPZEa5CJV1NjeiXIx9BELxEcEymqRWFnumsWFSBEgVQ2swtfbVSK2q7YTDqsX3iuUNUa5+h5EW3/CZ5/knkwvzSmcP8hQkqdVE77cEJ9Sha+jolwcBuLDAue77A71UGlys5BNxlMuIC1v4zUOPmMhdJ4vRcs3oq1NtlOX/Agd84kXcKMNFfc4iAD1CffGeUimWS50Ks4uYvaRSdYZaEwffdGQzPJWXvZIYdiuNWtadejbCucenqPttsM+WGkpfaTDVV6aeRjjXFHqiqKoL8t85hkWVd9G+RJV3kqGn/oCx4mHCv/O3qIAd6ln4DgnXmRGW+BPdEWJNqaHXUeR1gtbIQ7daLmflP7g9neqUi03Qkwq6WWJxSAjDEm3XIxXwMXdklRSN2rMywUFpDmGAwM784RsIpYv23gsAUhXYMQC1Y/8Ro9ACpohfcsoKqErGKLSnAMfyC+wlZ+JuV2rmEa/yAv1t1Fhx1MnnKjE5Q4MeMPW8NGO+g5IiKezIdCkFueLwgYKk+vP6bMt4ZAxdt8I/Zdc4dsrHjNZvlErhYcEUNXXZwtIVN3/qP1d01KRZMUaHZJm8vS9i1jscd3Uqp71G/tgxce3ic/VWBgpnHFJk19XT5PrKU+CJI1ZhPezREjes52iA3GUc0Fn3SJtHfVIQ5Wyl4pVIftPjXJzEXam/1MOgw3ThLIa6DAfkEeBguKnib7wqMXabE1A2/2oPxCfxxAGXz0QIDdWea/+PwxtKrq3mbeelY1p69C5TwfBMROgh hf4+eLOH En5qY0ympiviHDaf3LoSDQq3q/b0cFaXLV9wqu7ddMsKUJbu8qpvQhKytN6tHwILlFQVLS6NeVF5Z9rChe85ntkIlYI6oPQmVn4OLuJpBtEM4CrXGPXiXR4FmCLbTyrhXl37LtTeX8dBVpAVnAMM0Q9BEC0F2Zdh3kmZiIrKnkXtVoZDBlARk1/um8EVl3n7UC9+TAzJ+QEp4/TwLQQP8SblEWOLSHfSGYDbbZRdzLlddJ6tWIW7e6hXRRGpleuHP4ocXqVn4i3E3uKw= 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 Fri, Mar 03, 2023 at 02:14:55PM -0800, Luis Chamberlain wrote: > On Fri, Mar 03, 2023 at 03:07:55PM -0700, Keith Busch wrote: > > On Fri, Mar 03, 2023 at 01:45:48PM -0800, Luis Chamberlain wrote: > > > > > > You'd hope most of it is left to FS + MM, but I'm not yet sure that's > > > quite it yet. Initial experimentation shows just enabling > PAGE_SIZE > > > physical & logical block NVMe devices gets brought down to 512 bytes. > > > That seems odd to say the least. Would changing this be an issue now? > > > > I think you're talking about removing this part: > > > > --- > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > > index c2730b116dc68..2c528f56c2973 100644 > > --- a/drivers/nvme/host/core.c > > +++ b/drivers/nvme/host/core.c > > @@ -1828,17 +1828,7 @@ static void nvme_update_disk_info(struct gendisk *disk, > > unsigned short bs = 1 << ns->lba_shift; > > u32 atomic_bs, phys_bs, io_opt = 0; > > > > - /* > > - * The block layer can't support LBA sizes larger than the page size > > - * yet, so catch this early and don't allow block I/O. > > - */ > > - if (ns->lba_shift > PAGE_SHIFT) { > > - capacity = 0; > > - bs = (1 << 9); > > - } > > - > > blk_integrity_unregister(disk); > > - > > atomic_bs = phys_bs = bs; > > Yes, clearly it says *yet* so that begs the question what would be > required? Oh, gotcha. I'll work on a list of places it currently crashes. > Also, going down to 512 seems a bit dramatic, so why not just match the > PAGE_SIZE so 4k? Would such a comprmise for now break some stuff? The capacity set to zero ensures it can't be used through the block stack, so the logical block size limit is unused. 512 is just a default value. We only bring up the handle so you can administrate it with passthrough commands.