From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id CB8487D912 for ; Tue, 25 Jun 2019 23:03:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726376AbfFYXC4 (ORCPT ); Tue, 25 Jun 2019 19:02:56 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:42763 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbfFYXC4 (ORCPT ); Tue, 25 Jun 2019 19:02:56 -0400 Received: by mail-pg1-f194.google.com with SMTP id k13so165620pgq.9; Tue, 25 Jun 2019 16:02:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IAVXlfOigyJbEa5HhE6BwBcpEncScOxFXJXYNv1k45k=; b=fkL5OZuDVWkej5ZG4VatI21hHWlzGJXK0Si9AQAW9zoGDwMiyZEPuYRirz3Q0aByJu 9VSHMOkGBUWW+0XoBoEXFmw+r8dtWGNTMbrgcKs5Y6TE4ftvqTFwaaqA+U2WFhJQIFlw 4KKH74x4Ywbb000a83LtPoyMHZ5lCRuW/S7lvrp3MQNb3camzLJIdH0ezPRKVp/yWlMv 3/Q1tmNtE2UScpSpGJSN7CWBf4L/z22TrszMAenhqm81+BrbizGlhy6Mq2867Dogh+6s QTfxli/sBvaR+SMxqvkCI0RltTgT8RpA3KvJKAQJ31dHl2que9hlT0apwrDNqHfDlHEN pogA== X-Gm-Message-State: APjAAAUEy5rjIl2ApPQlP2hKVqp/KAyOmZgVXhTaR1V8Qxen5rTjMWmm DtEyG+GK0eMtcjV02R/Fmj4= X-Google-Smtp-Source: APXvYqzZBw/dqZhBTNHNMDfHye5/2eZRaAS1PSupftYRQhWIaCqeSFUapN9xTbqyZVwDxqRVbGqHHQ== X-Received: by 2002:a17:90a:ac13:: with SMTP id o19mr354796pjq.143.1561503775428; Tue, 25 Jun 2019 16:02:55 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id r1sm92074pji.15.2019.06.25.16.02.53 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 25 Jun 2019 16:02:54 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 64827401EB; Tue, 25 Jun 2019 23:02:53 +0000 (UTC) Date: Tue, 25 Jun 2019 23:02:53 +0000 From: Luis Chamberlain To: Brendan Higgins Cc: Stephen Boyd , Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Peter Zijlstra , Rob Herring , shuah , Theodore Ts'o , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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