From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71A694279EA for ; Thu, 26 Feb 2026 18:39:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772131158; cv=none; b=qdzX4BgkMjPnjwOJmLSBPk2EeQ2t3ex3o7OBspu97tyexqFZQTbTQPRn2hNc4EdILJRGwrL6Ckv68chDT6goyDqoIiRxwKkJjyyS9FFiHVesxG+QGJpy7m2MaXwEfXZJRL4ITsfPfDKlWx0SubnLOF3aDxLOv5+C0JJ/GaJ+g8s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772131158; c=relaxed/simple; bh=WXLJBRwPRH5Tybm6J8jtA40mG8q5sKCMY4FYsNnsoig=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=Orh6YSVL+J4sPMIkazUrX051kIrKuD0UXB7jNSjs6QHPMQ0EGI6crtGSs5cv+JscRjvaBKkFdBxZc1JQ0jrqxgI5r8hdrR/6SGiXQ5zBDDFLMgn+nUis3/rAlmZq6itg2LcBZPAdI4PsJqsu7Vd4TMlQ3ArbWrf3Wgcwh4dn1E8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FsKt6O16; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FsKt6O16" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772131153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WXLJBRwPRH5Tybm6J8jtA40mG8q5sKCMY4FYsNnsoig=; b=FsKt6O16OT8jZuzBFr5CfwbyJaEDcAIq5vUiNoJqcOFe+yMO2fEqPseAT3JFCI5k1OQ85e 231Awx4v9d0NCuFNLVGhN+Z6xxDTBW7HaNv5xxU5M18x81vzl/ciR3SfNU5XiEftWIVE+4 T8DssHbvIqemZ8cBHJ7iRlegC5zwlu4= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-217-fU0DZI2wPtiLT0TNB9XIxg-1; Thu, 26 Feb 2026 13:39:12 -0500 X-MC-Unique: fU0DZI2wPtiLT0TNB9XIxg-1 X-Mimecast-MFC-AGG-ID: fU0DZI2wPtiLT0TNB9XIxg_1772131151 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-48378df3469so7600115e9.1 for ; Thu, 26 Feb 2026 10:39:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772131151; x=1772735951; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WXLJBRwPRH5Tybm6J8jtA40mG8q5sKCMY4FYsNnsoig=; b=EVNCeAMwgQwU/dFXWWNKOvfFaG/9dXqdJgpMf5Ez4YJM+wC9mxYmihjyY0aWDiIVwV uCZ9Jjc+peZuxhLKnP2s6DOfi2GCoWC+D3q8XIyKXb2NF/iB2mA6TkA6IVB6S6Z3YHNh Y50gsI8m9+7/a0iAS4SObKOczf3ykBOeFUynIGlhUaYBagonPqK8Qy20+eCLwgTGQDdT RZYoEQwFRzvTvqcalZ1Fcg2dz/enRl7ADdoPGGiNea6Kn0NSrtOWDYnxAM9+OAHtKzji wPTEj0UpWDxjXPP8nnyU0C2NNHqjlVZ9AMQxP+DAKy+3W4FPyXX4K50OrJakAJJzCN17 jk1g== X-Forwarded-Encrypted: i=1; AJvYcCX53mK0Xg0TUGHyCKp3F33jo1JtUTDGWI/pvbt0SFgMWxwt1JutRXoaeMLu5X377ZLzVsTMJKw0QWLrM2qdE3qdYf4=@vger.kernel.org X-Gm-Message-State: AOJu0Yz20gA9NsXmSMe5xus7Uz2bDlbAlV4ui1Z6NMDonbYY8Xq/QbTB PJB0YKQzyG753lmWKrauISJr11qR4Anhqa9ZVoc4belLfQlPGrfa0aREpp9RlML5gm4MfGUOdnw zreiQk2jA7lHmmc/nvdrZLAJfPe/90tCCHE8uPaOIgLuW9lkWanvFePmvboH4kzeEVym3xQGE2A == X-Gm-Gg: ATEYQzyhZFZvd5ejywYuroAlT0oBFe/CAfwXVMuW7BULtsTx+WZmwFoqjs9JM41mlBq mvVGATldGomUxyvQoJWV0XW6GqXO6kc36mCAEkavv+hRZXkiCVGDjPT7sVKpIWH8VJSWF1GrPuJ a5H90Q1Vjg2nzO5+meKVmIAe2symx2z+jfH1G6ugtal30EB7JRmXjxryL+3GxW2+64YhCd/AZPw SYmACyPK9WxZyQA+WexGAMHFc1bnXgdzNOM2z4MsddpMVxM3VwYCuYzBD7bBD5PibnIavyFNMAu I07E9WjOJuRqGh2bfsk6BhHcmbFlKDhLdXHfS9onN4jQ8aV/fCKwTsS3OLKzzYkt6bXhdfRCYRy cVJV3t3kBCwgNpvZaVw== X-Received: by 2002:a05:600c:3544:b0:47a:8383:f2b2 with SMTP id 5b1f17b1804b1-483c33f3357mr65519325e9.17.1772131150832; Thu, 26 Feb 2026 10:39:10 -0800 (PST) X-Received: by 2002:a05:600c:3544:b0:47a:8383:f2b2 with SMTP id 5b1f17b1804b1-483c33f3357mr65518855e9.17.1772131150355; Thu, 26 Feb 2026 10:39:10 -0800 (PST) Received: from [127.0.0.1] ([195.174.33.230]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bd702e7bsm181703545e9.5.2026.02.26.10.39.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Feb 2026 10:39:10 -0800 (PST) Date: Thu, 26 Feb 2026 18:39:07 +0000 From: Gabriele Monaco To: Tejun Heo Cc: linux-kernel@vger.kernel.org, Andrea Righi , Joel Fernandes , Steven Rostedt , Nam Cao , Juri Lelli , Ingo Molnar , Peter Zijlstra , sched-ext@lists.linux.dev, Tomas Glozar , Clark Williams , John Kacur , linux-trace-kernel@vger.kernel.org Message-ID: In-Reply-To: References: <20260225095122.80683-1-gmonaco@redhat.com> <20260225095122.80683-15-gmonaco@redhat.com> <8fbc3ced19fb0c2a2171708073fa51ae308755b5.camel@redhat.com> Subject: Re: [PATCH v6 14/16] sched_ext: Export task_is_scx_enabled() for verification Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Correlation-ID: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4zp9zVgOqWNnZZMu7wzfB5k4lSwSvwfQ3-w1dfNL1QU_1772131151 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 2026-02-26T17:54:35Z Tejun Heo : > So, I don't know how rv works (searched a bit just now) but from kernel's > POV, it seems to look mostly like an additional tracing framework, and > testing p->sched_class against exported pointer value seems like a good fit > for the use case, no? It's not like task_on_scx() or state testing is going > to give you a "better" result anyway and it's actually rather confusing to > use them outside scheduler proper as these are expected to be used while the > task's rq lock is held. I don't think rv wants to (or even can) synchronize > against scheduler internals. Using external observability mechanism seems > like the better fit here. Yeah you got a gist of it, essentially RV would be running from the tracepoint contexts, so in this specific scenario it would be synchronised with the scheduler. Grabbing a pointer via kallsyms and comparing that will do exactly the same job, just a bit more "unofficially". I can do that if you think such an "official" function won't really be useful. Indeed if that function wouldn't make sense without the rq lock, tracepoints are probably the only valid use case.. Thanks, Gabriele