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 AC6CDC6379F for ; Fri, 17 Feb 2023 14:33:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229507AbjBQOdN (ORCPT ); Fri, 17 Feb 2023 09:33:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbjBQOdL (ORCPT ); Fri, 17 Feb 2023 09:33:11 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BECF62FC4 for ; Fri, 17 Feb 2023 06:33:09 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 31AB61FEC1; Fri, 17 Feb 2023 14:33:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676644388; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zopWuCQrC1rdeWoR6O5z7jiBljTWOgoFh6WvTassupc=; b=tn5vgPQzuZMEJ1LQ1jLTkSYBNzNm6hujX8veQrLZnPu2s45BRgvQG6fK2NV9HhDBhLaK11 aVuId/HQTLj3yEP+UkymJyKOqfGoUK7VHnrDIKtCTrao3feWGp00N93elA1gsu9mPJAHjQ getPaOIjcHc6l68MXDPavj+vHgbgu6c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676644388; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zopWuCQrC1rdeWoR6O5z7jiBljTWOgoFh6WvTassupc=; b=CODWux77/b9omo5+Z7Br8sl43wnI++2Bj1xRIJ1oY9MfqGFrPl/CKhq9THd3ybRIAgJQiQ m1zc/03OOyICPvBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1B55513274; Fri, 17 Feb 2023 14:33:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id PiGgBiSQ72ObIAAAMHmgww (envelope-from ); Fri, 17 Feb 2023 14:33:08 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 63E3CA06E1; Fri, 17 Feb 2023 15:33:07 +0100 (CET) Date: Fri, 17 Feb 2023 15:33:07 +0100 From: Jan Kara To: Johannes Thumshirn Cc: Hans Holmberg , Adam Manzanares , Hans Holmberg , "linux-fsdevel@vger.kernel.org" , "jaegeuk@kernel.org" , "josef@toxicpanda.com" , Matias =?utf-8?B?QmrDuHJsaW5n?= , Damien Le Moal , Dennis Maisenbacher , Naohiro Aota , Aravind Ramesh , =?utf-8?Q?J=C3=B8rgen?= Hansen , "mcgrof@kernel.org" , "javier@javigon.com" , "hch@lst.de" , "guokuankuan@bytedance.com" , "viacheslav.dubeyko@bytedance.com" , "j.granados@samsung.com" Subject: Re: [LSF/MM/BPF TOPIC]: File system data placement for zoned block devices Message-ID: <20230217143307.g774ouwddlyslqw7@quack3> References: <20230206134148.GD6704@gsv> <20230208171321.GA408056@bgt-140510-bm01> <61a40b61-2346-053d-1190-907075e1c9d2@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61a40b61-2346-053d-1190-907075e1c9d2@wdc.com> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu 09-02-23 10:22:31, Johannes Thumshirn wrote: > On 09.02.23 11:06, Hans Holmberg wrote: > > It takes a significant amount of time and trouble to build, run and understand > > benchmarks for these applications. Modeling the workloads using fio > > minimizes the set-up work and would enable more developers to actually > > run these things. The workload definitions could also help developers > > understanding what sort of IO that these use cases generate. > > True, but I think Adam has a point here. IIRC mmtests comes with some scripts > to download, build and run the desired applications and then do the maths. > > In this day and age people would probably want to use a container with the > application inside and some automation around it to run the benchmark and > present the results. Yeah, although containers also do have some impact on the benchmark behavior (not that much for IO but for scheduling and memory management it is more visible) so bare-metal testing is still worthwhile. Mmtests actually already have some support for VM testing and we have implemented basic container testing just recently. There are still rough edges and more work is needed but mmtests are also moving into the next decade ;). Honza -- Jan Kara SUSE Labs, CR