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.133.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 9979813B5AE for ; Fri, 27 Feb 2026 23:50:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772236202; cv=none; b=A70RgrO2BBMOPcg/CwlvrDZuvtE63ik0yRjOVIAQOUWl0V3ehUgki51LpFLENeopeTt+AVaV3aiXdokHxQfFw5Di9NkpSdGtAD+zDmBZ77MAq6GJakFvg6aQbXFEE7CAhUruBtU3zqHLcUBpYTo+QXuUWgWe13q/8DsNy4XBn1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772236202; c=relaxed/simple; bh=NrihneR5sbod2ovvW4lcqaZUv8IspioUNws1r49jcqo=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=YCGLbM7L9dQzakDhGAwKgxRxFgG12lQz4eHLWezQ1C5DM7D1NlqQvGVyli/+0rAZpuP4BV19Q58ayEI4/lEkYjBNu4xRcBE4OZrTOYHJexipIqoJW4vEQzDdFd2L9RNqNxwA0+2OqG4B3ua94mQg5/+mrwy3Kw5tH1mvyUDd+5o= 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=ZKpNt5am; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=JlhV/gzB; arc=none smtp.client-ip=170.10.133.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="ZKpNt5am"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="JlhV/gzB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772236199; 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=ww/Bhz3J3L+KhS5rSZm9FkdK6bU8Zv9mIU3Bpy6wyeY=; b=ZKpNt5amxQwnIFhcJL3y3qNrv7aa14CSSnhC1apjH9rtdQW9PnihsZW4ERkSNOJmZaiOdg M79Ywyogy6lCSk2unndFMqZiaxRWrntm0wkgo/xN4WfLPoMLkqf98lMJRsCSJy6/5eA0+M bC8a39jXNHVKzuOSAe3dJ8SHYfJM2h0= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-6-k9zQl3OVMSeqPW6oLiLXFQ-1; Fri, 27 Feb 2026 18:49:58 -0500 X-MC-Unique: k9zQl3OVMSeqPW6oLiLXFQ-1 X-Mimecast-MFC-AGG-ID: k9zQl3OVMSeqPW6oLiLXFQ_1772236198 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-8954ac30d79so276448766d6.3 for ; Fri, 27 Feb 2026 15:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772236198; x=1772840998; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ww/Bhz3J3L+KhS5rSZm9FkdK6bU8Zv9mIU3Bpy6wyeY=; b=JlhV/gzBO52e3onriipIEN373JU+b/xrFCDYm0Da76TQcT6es3UXq4RSdl6v4BPXX5 D0xC3KS9xCpquY1Q/ZzJNnSeJHzwcaRzwalpc0FIiD+VpEpqcxpWF5LFkTfrFXFu8dvO JWxhZWnB7SDkZQcSnybtRm27P21RmJzJfY4ta9YGpjbxgFTfOwHb1LcJXiWCfez5bkvU pqGaGtO+FnnpALT6bjseY33P0bkVEAI3OzXU9R1DBiMv9dhCwMNnUdwy5OZxp3yfFMSd /wY+ZtWjvzC8xaR+JtF1UYA2Wb2l6OeqYQUaUScj+NtiT7T+FsOsJX29v2vqeurnr+Dd 3imw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772236198; x=1772840998; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ww/Bhz3J3L+KhS5rSZm9FkdK6bU8Zv9mIU3Bpy6wyeY=; b=Fk0yhtzDgSrUuw/ZWaCE+fnkMU3p0yYm9bSqa9+gVzsDLigjQMVe/En7ISAEyK996S XQU6fQPISDzumieEGaWtluv+zwq7CPiWoGb8DdHpAjX4RUzQ4a/ugJ0arPdMqKiNOoXJ zuee87EUQPvsNYwObzbpePfUeVxfdY8kB+DJTr5tomZOsLYIjaECi3/EwWTHSPaaJY3P NmuDhEBevx5uOjMAoji8TGo2xvaaTbcc1dl9OLXcxKQl+1ldnFZA6XJTesm6oNe+HtcK UvjJniCn2d9CjRbCsbMbtGN2svojfbM8pcTS77JD8XpOqgGQwJZ8QAGy/noPaCseiKG3 hrvA== X-Forwarded-Encrypted: i=1; AJvYcCUmeqzMWrJlasbtGs8J6/vBLOg/OfMcX2410+BYtFPxFCX6TaUjOP95KPzethh5ioY+WiJpXs8E9wk4xRM=@vger.kernel.org X-Gm-Message-State: AOJu0Yxpr4Pqcdd1VbyvJ2iZ6W4Pk/ygJymxdVk9/1GzAEr6+rQuz7/Q eghwQjN+xibL/5V5P3a9ONxAU8xi80Nj9XvJ4lM2NQEoHEbN5XyxxmMU4za8BckFRffEdqiGsv5 En0LdzccwwH8vK3VD4apcsE2HGwYKqltOWFSG0j/IrflqdCPnxq2A/9+qxhzYldBphg== X-Gm-Gg: ATEYQzw5SzZxMkhd+NB7+XC1p/g0ib5ymHB7Pd9CZq94ckjrwCbIjjXaRQZyPjK+2vM PooYpXogl/OBtx+KC8CQ3c0+EXeFVS8Mp9MdGwQRIxXYNoQCnS9DuKQPBls3fS88/NQN6qI3Txp eQ1HIcbAkfaAENRLBGk0Az84FjFKYn8Bexq8i7iSi9fXI/NATarcZRiKM+IWlyWj6l6tyzo8ntT vcL1MDn5KYjJD8BZiYDi7gx8/wG2c37k2Eia39EHUptEHas1BIbCMMIUGsFapzmtCnX0Ij0E4+h CR9LoUrtV6nxG9tCjmQsvxIiAg8LTFzbXxauibuf4enCwy8CjsQArgpnMXKuHSSUlTUoxC2YX7U WG9Zoz9PiR4W2/jBiKDgWFWK+BdHmqXwEViupNgnbMFJlwVoNN94hqg== X-Received: by 2002:a05:6214:491:b0:894:6622:a6d4 with SMTP id 6a1803df08f44-899d1f49c66mr69077826d6.61.1772236197911; Fri, 27 Feb 2026 15:49:57 -0800 (PST) X-Received: by 2002:a05:6214:491:b0:894:6622:a6d4 with SMTP id 6a1803df08f44-899d1f49c66mr69077546d6.61.1772236197396; Fri, 27 Feb 2026 15:49:57 -0800 (PST) Received: from crwood-thinkpadp16vgen1.minnmso.csb ([2601:447:cc81:56d0:ab94:b2cb:29a6:7ac0]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cbbf678156sm662047785a.18.2026.02.27.15.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:49:57 -0800 (PST) Message-ID: Subject: Re: [PATCH] tracing/osnoise: Add option to align tlat threads From: Crystal Wood To: Tomas Glozar , Steven Rostedt , Masami Hiramatsu Cc: Mathieu Desnoyers , John Kacur , Luis Goncalves , Costa Shulyupin , Wander Lairson Costa , LKML , linux-trace-kernel Date: Fri, 27 Feb 2026 17:49:55 -0600 In-Reply-To: <20260227150420.319528-1-tglozar@redhat.com> References: <20260227150420.319528-1-tglozar@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-02-27 at 16:04 +0100, Tomas Glozar wrote: > Add an option called TIMERLAT_ALIGN to osnoise/options, together with a > corresponding setting osnoise/timerlat_align_us. >=20 > This option sets the alignment of wakeup times between different > timerlat threads, similarly to cyclictest's -A/--aligned option. If > TIMERLAT_ALIGN is set, the first thread that reaches the first cycle > records its first wake-up time. Each following thread sets its first > wake-up time to a fixed offset from the recorded time, and incremenets > it by the same offset. Why not just set the initial timer expiration to be=20 "period + cpu * align_us"? Then you wouldn't need any interaction between CPUs. > kernel/trace/trace_osnoise.c | 34 +++++++++++++++++++++++++++++++++- > 1 file changed, 33 insertions(+), 1 deletion(-) Documentation needs to be updated as well. Should mention that updating align_us while the timer is running won't take effect immediately (unlike period, which does). > diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c > index dee610e465b9..df1d4529d226 100644 > --- a/kernel/trace/trace_osnoise.c > +++ b/kernel/trace/trace_osnoise.c > @@ -58,6 +58,7 @@ enum osnoise_options_index { > OSN_PANIC_ON_STOP, > OSN_PREEMPT_DISABLE, > OSN_IRQ_DISABLE, > + OSN_TIMERLAT_ALIGN, > OSN_MAX > }; > =20 > @@ -66,7 +67,8 @@ static const char * const osnoise_options_str[OSN_MAX] = =3D { > "OSNOISE_WORKLOAD", > "PANIC_ON_STOP", > "OSNOISE_PREEMPT_DISABLE", > - "OSNOISE_IRQ_DISABLE" }; > + "OSNOISE_IRQ_DISABLE", > + "TIMERLAT_ALIGN" }; Do we really need a flag for this, or can we just interpret a non-zero align_us value as enabling the feature? > @@ -1820,6 +1824,7 @@ static int wait_next_period(struct timerlat_variabl= es *tlat) > { > ktime_t next_abs_period, now; > u64 rel_period =3D osnoise_data.timerlat_period * 1000; > + static atomic64_t align_next; How will this get reset if the tracer is stopped and restarted? > now =3D hrtimer_cb_get_time(&tlat->timer); > next_abs_period =3D ns_to_ktime(tlat->abs_period + rel_period); > @@ -1829,6 +1834,17 @@ static int wait_next_period(struct timerlat_variab= les *tlat) > */ > tlat->abs_period =3D (u64) ktime_to_ns(next_abs_period); > =20 > + if (test_bit(OSN_TIMERLAT_ALIGN, &osnoise_options) && !tlat->count > + && atomic64_cmpxchg_relaxed(&align_next, 0, tlat->abs_period)) { > + /* > + * Align thread in first cycle on each CPU to the set alignment. > + */ > + tlat->abs_period =3D atomic64_fetch_add_relaxed(osnoise_data.timerlat_= align_us * 1000, > + &align_next); > + tlat->abs_period +=3D osnoise_data.timerlat_align_us * 1000; > + next_abs_period =3D ns_to_ktime(tlat->abs_period); > + } I'm already unclear about the existing purpose of next_abs_period, but if it has any use at all shouldn't it be to avoid writing intermediate values like this back to tlat? -Crystal