From: Thomas Gleixner <tglx@linutronix.de>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Benjamin Segall <bsegall@google.com>,
Eric Dumazet <edumazet@google.com>,
Andrey Vagin <avagin@openvz.org>,
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [patch V2 10/17] posix-timers: Make signal_struct::next_posix_timer_id an atomic_t
Date: Wed, 05 Mar 2025 08:31:21 +0100 [thread overview]
Message-ID: <87ikoo53xy.ffs@tglx> (raw)
In-Reply-To: <Z8d7tm5dQN6dZEvu@grain>
On Wed, Mar 05 2025 at 01:16, Cyrill Gorcunov wrote:
> Thanks for handling this) Also looking into this series I wonder why can't
> we instead of mangling ::it_signal zero bit just use ::it_id with negative
> value as a sign of not yet fully initialized timer? This would allow to not
> read-modify action while traversing bucket hash chain. I mean we could do
>
> static bool posix_timer_add_at(struct k_itimer *timer, struct signal_struct *sig, unsigned int id)
> {
> struct timer_hash_bucket *bucket = hash_bucket(sig, id);
>
> scoped_guard (spinlock, &bucket->lock) {
> if (!posix_timer_hashed(bucket, sig, id)) {
> ---> timer->it_id = -(timer_t)id;
> timer->it_signal = (struct signal_struct *)((unsigned long)sig | 1UL);
> hlist_add_head_rcu(&timer->t_hash, &bucket->head);
> return true;
> }
> }
> return false;
> }
>
> Then hash traverse won't find the timer until the do_timer_create will do
>
> scoped_guard (spinlock_irq, ¤t->sighand->siglock) {
> WRITE_ONCE(new_timer->it_id, abs(new_timer->it_id));
> hlist_add_head_rcu(&new_timer->list, ¤t->signal->posix_timers);
> }
>
> Or I miss something obvious? (Of course when deleting timer we will have to pass
> abs it_id for hash traversing).
>
> It looks that in case of many many timers present in the system traversing hash
> in read-modify way might be heavy (though I didn't measure of course).
The traversal does not RMW the timer itself, it unmangles the signal
pointer for comparison in posix_timer_hashed(). posix_timer_by_id() does
straight comparisons. So both only read.
Sure, we can mangle timer ID instead of the signal pointer, but the
outcome is pretty much the same. The only difference is in
posix_timer_hashed(), which must detect a taken timer ID independent of
the timers valid state to prevent collisions.
With the signal pointer mangling we have:
if ((timer->signal & ~1) == sig && timer->id == id)
and with the negative ID value this becomes:
if (timer->signal == sig && (timer->id == id || timer->id == -id))
which is obviously worse. You'd need to do:
timer->id = id | (1 << 31);
and then the posix_timer_hashed() check becomes:
if (timer->signal == sig && (timer->id & ~(1 << 31)) == id)
Granted, the timer ID mangling spares the AND operation on the signal in
case the timer is not owned by the currrent process, but I doubt that
this is even measurable.
Thanks,
tglx
next prev parent reply other threads:[~2025-03-05 7:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-02 19:36 [patch V2 00/17] posix-timers: Rework the global hash table and provide a sane mechanism for CRIU Thomas Gleixner
2025-03-02 19:36 ` [patch V2 01/17] posix-timers: Initialise timer before adding it to the hash table Thomas Gleixner
2025-03-05 17:25 ` Frederic Weisbecker
2025-03-06 8:10 ` Thomas Gleixner
2025-03-06 8:47 ` Frederic Weisbecker
2025-03-07 13:46 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 02/17] posix-timers: Add cond_resched() to posix_timer_add() search loop Thomas Gleixner
2025-03-05 20:54 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 03/17] posix-timers: Cleanup includes Thomas Gleixner
2025-03-05 20:57 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 04/17] posix-timers: Remove a few paranoid warnings Thomas Gleixner
2025-03-05 22:11 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 05/17] posix-timers: Remove SLAB_PANIC from kmem cache Thomas Gleixner
2025-03-07 14:05 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 06/17] posix-timers: Use guards in a few places Thomas Gleixner
2025-03-07 14:16 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 07/17] posix-timers: Simplify lock/unlock_timer() Thomas Gleixner
2025-03-07 22:16 ` Frederic Weisbecker
2025-03-02 19:36 ` [patch V2 08/17] posix-timers: Rework timer removal Thomas Gleixner
2025-03-04 10:10 ` Pavel Tikhomirov
2025-03-04 10:20 ` Pavel Tikhomirov
2025-03-04 14:06 ` Thomas Gleixner
2025-03-07 23:03 ` Frederic Weisbecker
2025-03-08 8:34 ` Thomas Gleixner
2025-03-08 22:48 ` Frederic Weisbecker
2025-03-09 8:21 ` Thomas Gleixner
2025-03-02 19:36 ` [patch V2 09/17] posix-timers: Make lock_timer() use guard() Thomas Gleixner
2025-03-04 14:08 ` [patch V2a " Thomas Gleixner
2025-03-02 19:36 ` [patch V2 10/17] posix-timers: Make signal_struct::next_posix_timer_id an atomic_t Thomas Gleixner
2025-03-03 20:21 ` Cyrill Gorcunov
2025-03-03 21:24 ` Thomas Gleixner
2025-03-04 17:56 ` Cyrill Gorcunov
2025-03-04 20:30 ` Thomas Gleixner
2025-03-04 22:16 ` Cyrill Gorcunov
2025-03-05 7:31 ` Thomas Gleixner [this message]
2025-03-05 8:28 ` Cyrill Gorcunov
2025-03-02 19:37 ` [patch V2 11/17] posix-timers: Improve hash table performance Thomas Gleixner
2025-03-02 19:37 ` [patch V2 12/17] posix-timers: Switch to jhash32() Thomas Gleixner
2025-03-02 19:37 ` [patch V2 13/17] posix-timers: Avoid false cacheline sharing Thomas Gleixner
2025-03-02 19:37 ` [patch V2 14/17] posix-timers: Make per process list RCU safe Thomas Gleixner
2025-03-02 19:37 ` [patch V2 15/17] posix-timers: Dont iterate /proc/$PID/timers with sighand::siglock held Thomas Gleixner
2025-03-02 19:37 ` [patch V2 16/17] posix-timers: Provide a mechanism to allocate a given timer ID Thomas Gleixner
2025-03-02 19:37 ` [patch V2 17/17] selftests/timers/posix-timers: Add a test for exact allocation mode Thomas Gleixner
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=87ikoo53xy.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=avagin@openvz.org \
--cc=bsegall@google.com \
--cc=edumazet@google.com \
--cc=frederic@kernel.org \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=ptikhomirov@virtuozzo.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox