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 F0FBDC4332F for ; Mon, 7 Mar 2022 21:28:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245458AbiCGV3J (ORCPT ); Mon, 7 Mar 2022 16:29:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236560AbiCGV3I (ORCPT ); Mon, 7 Mar 2022 16:29:08 -0500 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CD821FA57 for ; Mon, 7 Mar 2022 13:28:13 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id d17so6677662pfv.6 for ; Mon, 07 Mar 2022 13:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PImHJe2UAKTKdLzbka2oPzbR4jyxspwMY4yN+DC78os=; b=YIwcUYinBHuQkOw71MFOJWXaviYwDf15Zt5dUlHw84q4j9Oc2/RPyplay1J6d8oA8J 6llbD5EBv8KpGaTOmo8ubzhcn4XVaMCoJ4tfZHncBCvOj+o4lYL6gbtLjah7KvbaJos0 V4jPV3R8UjHI6WMXCHQPpAbebPTxZjmnBLWKMZTiiMSrF1xMH85S1MdVQNueDJuazC+N VUzW8sUj8xICv6NIlCIo3Mu7OJRwGl1L8oQHm6LXCZfG5lMEW6PFATgnWGxJgD37CoR/ w0B/JTTUsxeqCxM8+st3XJUzoHNB03Cpcu2FTkL9wkkVnDjZfxcV1LDbdHFAmV6N+I92 mq4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PImHJe2UAKTKdLzbka2oPzbR4jyxspwMY4yN+DC78os=; b=4wdPhkLyh4Y+yoq54ukdxkCu/Skr5fvw3ysrXdnmNkJlMqqG9I0jS4GpQysd9iXU0V HVktDN7/HLjTY7mCNa6j1QxnlvRBA6KgMTSw9TOcCy9qn+fW3WiViaZ0802x2jIhiIp6 kGn39xQH80E0HyL+Ai+WnsLCWa58yrqShaLAcmQAiQuOLQVwlcB++YQFNoOKZP/sHRUg qFaCYrqsjqDtD+sA/XEAQovUGhgfmSj+uFhzIxzSDSYyNard6475XSxopBB+xuoiIWRM o/yypNbrnoiyZfRyfrJ1v+lNXp2rjfKkFGsYcMCmnblxWRMMU31g9IrCKspJ36mPJKWU bIng== X-Gm-Message-State: AOAM530IwqhcK41aEbnJvr+5y3Lzqp+rfV3w9bKWTjP/b55JrQdOQFdr RgSTHqpCsll/IUeSGf3EGTx8j1YuEqp7Ti4kixLXUA== X-Google-Smtp-Source: ABdhPJwuLzmS+KlSHxrMx4r8+wjAkPbvfS39sMJUhbtoQlDMdOBplYzGmTuAc3AWOm7gWL9xtmeUhJBVldl1o9SJVLk= X-Received: by 2002:a05:6a02:283:b0:342:703e:1434 with SMTP id bk3-20020a056a02028300b00342703e1434mr11374652pgb.74.1646688492661; Mon, 07 Mar 2022 13:28:12 -0800 (PST) MIME-Version: 1.0 References: <20220301195457.21152-1-jithu.joseph@intel.com> <20220301195457.21152-9-jithu.joseph@intel.com> <188492dc80c017375da76d444347b1d00c2031f6.camel@intel.com> <7b9c788e-21dc-eedc-a1b4-9c6877fa48fe@intel.com> <33d0e764-86d9-8504-17fa-14b31c87de4e@intel.com> <7c620f8a-189e-5ac4-30fe-1fa14ba799ea@intel.com> In-Reply-To: From: Dan Williams Date: Mon, 7 Mar 2022 13:28:04 -0800 Message-ID: Subject: Re: [RFC 08/10] platform/x86/intel/ifs: Add IFS sysfs interface To: "Joseph, Jithu" Cc: "hdegoede@redhat.com" , "markgross@kernel.org" , "corbet@lwn.net" , "Raj, Ashok" , "Luck, Tony" , "dave.hansen@linux.intel.com" , "patches@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "mingo@redhat.com" , "rostedt@goodmis.org" , "Shankar, Ravi V" , "tglx@linutronix.de" , "platform-driver-x86@vger.kernel.org" , "linux-doc@vger.kernel.org" , "hpa@zytor.com" , "bp@alien8.de" , "gregkh@linuxfoundation.org" , "andriy.shevchenko@linux.intel.com" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 7, 2022 at 12:56 PM Joseph, Jithu wrote: > > > > On 3/7/2022 12:25 PM, Dan Williams wrote: > > > > > I am speaking of the state of the case where 2 threads are doing > > run_test and polling for results. Unless you can guarantee that run2 > > does not start before the results of run1 have been collected then > > they are lost in that scenario. No amount of kernel locking can > > resolve that race to collect previous result which would not be a > > problem in the first place if there was an atomic way to log test > > results. > > > Yes "status" shows the status of the latest run. You cannot get the status of the previous run. > > Also some context on test frequency: Hardware has strict rate limiting of tests. > Every core can be tested only once in every 30 minutes. So it is pointless to test at high frequency. Is that enforced in the ABI? Did I miss that detail in the documentation? Does that per-core time limitation also mitigate the race to read the global status? I.e. back-to-back tests on the same core may need to be spaced by 30 minutes, but between different cores as well. Again, these are questions that can not even be posed with an ABI that eliminates the possibility of result races like uevent. Please think through that suggestion, that's my main motivation for continuing to poke at this ABI as currently presented.