From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 245622129F059 for ; Tue, 25 Jun 2019 16:02:56 -0700 (PDT) Received: by mail-pf1-f195.google.com with SMTP id y15so189392pfn.5 for ; Tue, 25 Jun 2019 16:02:56 -0700 (PDT) Date: Tue, 25 Jun 2019 23:02:53 +0000 From: Luis Chamberlain Subject: Re: [PATCH v5 01/18] kunit: test: add KUnit test runner core Message-ID: <20190625230253.GQ19023@42.do-not-panic.com> References: <20190617082613.109131-1-brendanhiggins@google.com> <20190617082613.109131-2-brendanhiggins@google.com> <20190620001526.93426218BE@mail.kernel.org> <20190625214427.GN19023@42.do-not-panic.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Brendan Higgins Cc: Petr Mladek , "open list:DOCUMENTATION" , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , Rob Herring , linux-nvdimm , Frank Rowand , Knut Omang , Kieran Bingham , wfg@linux.intel.com, Joel Stanley , David Rientjes , Jeff Dike , Dan Carpenter , devicetree , linux-kbuild , "Bird, Timothy , linux-um@lists.infradead.org, Steven Rostedt" , Julia Lawall , Josh Poimboeuf , kunit-dev@googlegroups.com, Theodore Ts'o , Richard Weinberger , Stephen Boyd , Greg KH , Randy Dunlap , Linux Kernel Mailing List , Daniel Vetter , Kees Cook , linux-fsdevel@vger.kernel.org, Kevin Hilman List-ID: On Tue, Jun 25, 2019 at 03:14:45PM -0700, Brendan Higgins wrote: > On Tue, Jun 25, 2019 at 2:44 PM Luis Chamberlain wrote: > > Since its a new architecture and since you seem to imply most tests > > don't require locking or even IRQs disabled, I think its worth to > > consider the impact of adding such extreme locking requirements for > > an initial ramp up. > > Fair enough, I can see the point of not wanting to use irq disabled > until we get someone complaining about it, but I think making it > thread safe is reasonable. It means there is one less thing to confuse > a KUnit user and the only penalty paid is some very minor performance. One reason I'm really excited about kunit is speed... so by all means I think we're at a good point to analyze performance optimizationsm if they do make sense. While on the topic of parallization, what about support for running different test cases in parallel? Or at the very least different kunit modules in parallel. Few questions come up based on this prospect: * Why not support parallelism from the start? * Are you opposed to eventually having this added? For instance, there is enough code on lib/test_kmod.c for batching tons of kthreads each one running its own thing for testing purposes which could be used as template. * If we eventually *did* support it: - Would logs be skewed? - Could we have a way to query: give me log for only kunit module named "foo"? Luis _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm