All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Andrea Righi <arighi@nvidia.com>
Cc: David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	David Dai <david.dai@linux.dev>,
	Yonghong Song <yonghong.song@linux.dev>,
	Alexei Starovoitov <ast@kernel.org>,
	bpf@vger.kernel.org, sched-ext@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH sched_ext/for-7.4] sched_ext: Work around pahole 1.32 dropping scx_bpf_task_set_lazy_resched() from BTF
Date: Tue, 29 Sep 2026 09:25:02 -1000	[thread overview]
Message-ID: <arwQjsHCGl5lF7LR@slm.duckdns.org> (raw)
In-Reply-To: <arwPVufx2ZUOc_sp@gpd4>

On Tue, Sep 29, 2026 at 09:19:50PM +0200, Andrea Righi wrote:
> First of all thanks for figuring this out, it was really annoying, I've been
> holding pahole to 1.31 because of this.
> 
> I also looked a bit and it seems to be triggered specifically by the bool type.
> This is with clang 22.1.8 on x86_64 without barrier_data and only changing the
> type:
> 
>   bool  movl %esi, %ebp    -> dropped by pahole
>   u32   movl %esi, %ebp    -> ok
>   u64   movq %rsi, %r15    -> ok
> 
> With u32 the generated code is identical to the bool case, but clang keeps the
> RSI entry range, so pahole is happy.
> 
> Should we just change lazy to u32 (or use a u64 flags) instead of using
> barrier_data()?

I mean, bool is the right and I'm hoping clang can be fixed and the
workaround seems to work, so keep it as-is unless there are other reasons to
change it (e.g. this becomes a wider interface taking u64 flags or sth like
that)?

Thanks.

-- 
tejun

  reply	other threads:[~2026-09-29 19:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 17:32 [PATCH sched_ext/for-7.4] sched_ext: Work around pahole 1.32 dropping scx_bpf_task_set_lazy_resched() from BTF Tejun Heo
2026-09-29 17:38 ` sashiko-bot
2026-09-29 19:19 ` Andrea Righi
2026-09-29 19:25   ` Tejun Heo [this message]
2026-09-29 19:37     ` Andrea Righi
2026-09-29 23:11 ` Tejun Heo
2026-09-30  0:59 ` bot+bpf-ci

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arwQjsHCGl5lF7LR@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=changwoo@igalia.com \
    --cc=david.dai@linux.dev \
    --cc=emil@etsalapatis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=void@manifault.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.