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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C500C64EC4 for ; Sat, 4 Mar 2023 19:04:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229471AbjCDTE2 (ORCPT ); Sat, 4 Mar 2023 14:04:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjCDTE2 (ORCPT ); Sat, 4 Mar 2023 14:04:28 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70CF91714C; Sat, 4 Mar 2023 11:04:27 -0800 (PST) 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-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gk7SjEpw3fRez1WAUe0E4mRcDbNV5fQmNUi1Uz2ZLys=; b=xdenxezCvtxLJClr279s1BNnLa caKlctrkgiAqM8+dwFbBO4LJgVrzN+uMtwNZEthCmLFh9iScomz7ueJIMNwjJpKCD97422QoVQ8a/ KMhGmsKe/pdBdYS00M7nH1GBRsAOAQ/MAR+kToApg9A5WShYE72nt+bgN8tteZKYXmgHcyA0Us3lk Wc6XrsH8oe4rRPEW4ZdOCHo1/xnGes8OAWrZ726juNhPcTbIoVfUzBBp/LHAXVsDE0cuH/fXiB30O 9SE7DkGGgxY1aVG/B5+N22V2c765XW07NfJJlPVrId7wab0qzYRwjBSF10ZDyhMRGplHgm50AiFuo 7a9l+nIw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pYXB7-009R33-28; Sat, 04 Mar 2023 19:04:21 +0000 Date: Sat, 4 Mar 2023 11:04:21 -0800 From: Luis Chamberlain To: Matthew Wilcox Cc: James Bottomley , Keith Busch , Theodore Ts'o , Javier =?iso-8859-1?Q?Gonz=E1lez?= , Pankaj Raghav , Daniel Gomez , 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: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Sat, Mar 04, 2023 at 07:34:33AM +0000, Matthew Wilcox wrote: > The hard part is plugging your ears to the screams of the MM people > who are convinced that fragmentation will make it impossible to mount > your filesystem. One doesn't just need to plug your ears, one can also be prepared for that, should that actually end up being true, because frankly we don't have the evidence yet. And it's something I have slowly started to think about -- because -- why not be ready? In fact let's say the inverse is true, having the tooling to proove them wrong is also a desirable outcome and that begs the question of proper tooling to measure this, etc. Something probably more for an MM track. What would satifsy proof and what tooling / metrics used? It is *not* something that only is implicated by storage IO controllers and so what we're looking at a generic device issue / concern for memory fragmentation. *If* the generalization of huge page uses for something like bpf-prog-pack ends up materializing and we end up using it for even *all* module .text, *then* I *think* it something similar be a way to address that concern for devices with huge pages for CMA. This is one area where I think device hints for large IO might come in handy, we can limit such dedicated pools to only devices with hints and limit the amount of huge pages used for this purpose. But ask me 2 kernel releases from now again. Luis