Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3714148ybv; Sun, 16 Feb 2020 04:06:58 -0800 (PST) X-Google-Smtp-Source: APXvYqw07tV0YSuPplRAmKhvOZcHBBWU2xsRulbGsmo4sO/qP9jiY4C9rc7HXzYCBJeS9FbdxeQS X-Received: by 2002:a9d:53cb:: with SMTP id i11mr8990960oth.158.1581854818232; Sun, 16 Feb 2020 04:06:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581854818; cv=none; d=google.com; s=arc-20160816; b=Po3zF1R579OgItWRbIYveZkcFLWHnvJj1ZlPUQhv53vBZ50tb4H5F60tUmblXmG68s jizNelp0bJtODoGxMJ9rHQULMM5RBV5fz9d4cuU+YzHdxzE3l96MulpPHfpeOXdx+/uU jzI6Ld0v6/uuEugl4rsS5awJjtyuGPWpOjTOLJOHHSniS4VqiZOvthSbOTTlCthGdX/R zusR4iecPVAdQmf0WNTlHSUiybaTveOujSBfddXXWyRisP3N5wyPomkIMKQkMKzFrEVW auhQLRdNsJ/LRkpywWQ/cRDHOiNPSuUuxkvI/sotpt/fegU/rvvAjFKBocAulqeR3z7j qBTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=CPDxrKj4Q+BvZlVXoa6hMzgOwdxeVU8z6nnayfhWpDA=; b=Y0xFq/FWdC/60NQAALMIfdS9x7+hRmPy7jvn2NzBOF/T4PdqUEIKr2e2HjNhYvLKZf JA5GPkoIk9xtriy05+hUePQMTsxPdAZw2MpoeK0XZ49OzB64PCvJ7u2hoJmvi15O/Dyd YNw8eTh8LFlNv3Ye3HKwGKNY5w/P70AKLWi+vVWyhqq+nN0DpF5sOEDSgDaJuSIT0GuI zW8yaIR5BIiypOWiPVjHD3KvWnWX1piO2AGjQnAK65OBtZ6JhjAyaARKPSJDJYOzNwdk 1Yu34XEMwVAdg74wlVK8ak/g5NNcKzoKuMluKmJsFsMgRrmO9mRo3+bzI+YnYow/SZIW zIwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=G4v58wtD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p19si5930554otk.251.2020.02.16.04.06.46; Sun, 16 Feb 2020 04:06:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=G4v58wtD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728128AbgBPMGc (ORCPT + 99 others); Sun, 16 Feb 2020 07:06:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:53420 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728054AbgBPMGb (ORCPT ); Sun, 16 Feb 2020 07:06:31 -0500 Received: from paulmck-ThinkPad-P72.home (unknown [12.246.51.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 76BB320857; Sun, 16 Feb 2020 12:06:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581854790; bh=5vJUzMFXgL+4htCa+i0lvCczJshCVNG4PgJkkf3GTn0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=G4v58wtDrELJRfS6Y38HFJ/9cGmG8sXllwsX+m3TSNbAJoIyXj/LPU5HbBBLnqYWl aokWpFNpGiKSCEyCF5l3RhxdQFZWKrTGF6fUbhm4EvOvkxBxb4DlYKTaAegV9gTP9k ut4Yll6I+C/pvicdDRM3vUtgmWZ2l4EFUhdGUWqk= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id E3ECB352168B; Sun, 16 Feb 2020 04:06:25 -0800 (PST) Date: Sun, 16 Feb 2020 04:06:25 -0800 From: "Paul E. McKenney" To: Boqun Feng Cc: Alan Stern , linux-kernel@vger.kernel.org, Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Jonathan Corbet , linux-arch@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [RFC 0/3] tools/memory-model: Add litmus tests for atomic APIs Message-ID: <20200216120625.GF2935@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200214040132.91934-1-boqun.feng@gmail.com> <20200215152550.GA13636@paulmck-ThinkPad-P72> <20200216054345.GA69864@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200216054345.GA69864@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 16, 2020 at 01:43:45PM +0800, Boqun Feng wrote: > On Sat, Feb 15, 2020 at 07:25:50AM -0800, Paul E. McKenney wrote: > > On Fri, Feb 14, 2020 at 10:27:44AM -0500, Alan Stern wrote: > > > On Fri, 14 Feb 2020, Boqun Feng wrote: > > > > > > > A recent discussion raises up the requirement for having test cases for > > > > atomic APIs: > > > > > > > > https://lore.kernel.org/lkml/20200213085849.GL14897@hirez.programming.kicks-ass.net/ > > > > > > > > , and since we already have a way to generate a test module from a > > > > litmus test with klitmus[1]. It makes sense that we add more litmus > > > > tests for atomic APIs into memory-model. > > > > > > It might be worth discussing this point a little more fully. The > > > set of tests in tools/memory-model/litmus-tests/ is deliberately rather > > > limited. Paul has a vastly more expansive set of litmus tests in a > > > GitHub repository, and I am doubtful about how many new tests we want > > > to keep in the kernel source. > > > > Indeed, the current view is that the litmus tests in the kernel source > > tree are intended to provide examples of C-litmus-test-language features > > and functions, as opposed to exercising the full cross-product of > > Linux-kernel synchronization primitives. > > > > For a semi-reasonable subset of that cross-product, as Alan says, please > > see https://github.com/paulmckrcu/litmus. > > > > For a list of the Linux-kernel synchronization primitives currently > > supported by LKMM, please see tools/memory-model/linux-kernel.def. > > > > So how about I put those atomic API tests into a separate directory, say > Documentation/atomic/ ? > > The problem I want to solve here is that people (usually who implements > the atomic APIs for new archs) may want some examples, which can help > them understand the API requirements and test the implementation. And > litmus tests are the perfect tool here (given that them can be > translated to test modules with klitmus). And I personally really think > this is something the LKMM group should maintain, that's why I put them > in the tools/memory-model/litmus-tests/. But I'm OK if we end up > deciding those should be put outside that directory. Good point! However, we should dicuss this with the proposed beneficiaries, namely the architecture maintainers. Do they want it? If so, where would they like it to be? How should it be organized? In the meantime, I am more than happy to accept litmus tests into the github archive. So how would you like to proceed? Thanx, Paul > Regards, > Boqun > > > > Perhaps it makes sense to have tests corresponding to all the examples > > > in Documentation/, perhaps not. How do people feel about this? > > > > Agreed, we don't want to say that the set of litmus tests in the kernel > > source tree is limited for all time to the set currently present, but > > rather that the justification for adding more would involve useful and > > educational examples of litmus-test features and techniques rather than > > being a full-up LKMM test suite. > > > > I would guess that there are litmus-test tricks that could usefully > > be added to tools/memory-model/litmus-tests. Any nomination? Perhaps > > handling CAS loops while maintaining finite state space? Something else? > > > > Thanx, Paul