All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juri Lelli <juri.lelli@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, netdev <netdev@vger.kernel.org>,
	Valentin Schneider <vschneid@redhat.com>
Subject: Question on tw_timer TIMER_PINNED
Date: Wed, 6 Sep 2023 13:58:52 +0200	[thread overview]
Message-ID: <ZPhpfMjSiHVjQkTk@localhost.localdomain> (raw)

Hi Eric,

I'm bothering you with a question about timewait_sock tw_timer, as I
believe you are one of the last persons touching it sometime ago. Please
feel free to redirect if I failed to git blame it correctly.

At my end, latency spikes (entering the kernel) have been reported when
running latency sensitive applications in the field (essentially a
polling userspace application that doesn't want any interruption at
all). I think I've been able to track down one of such interruptions to
the servicing of tw_timer_handler. This system isolates application CPUs
dynamically, so what I think it happens is that at some point tw_timer
is armed on a CPU, and it is PINNED to that CPU, meanwhile (before the
60s timeout) such CPU is 'isolated' and the latency sensitive app
started on it. After 60s the timer fires and interrupts the app
generating a spike.

I'm not very familiar with this part of the kernel and from staring
at code for a while I had mixed feeling about the need to keep tw_timer
as TIMER_PINNED. Could you please shed some light on it? Is it a strict
functional requirement or maybe a nice to have performance (locality I'd
guess) improvement? Could we in principle make it !PINNED (so that it
can be moved/queued away and prevent interruptions)?

Thanks a lot in advance!
Juri


             reply	other threads:[~2023-09-06 11:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06 11:58 Juri Lelli [this message]
2023-09-06 12:10 ` Question on tw_timer TIMER_PINNED Eric Dumazet
2023-09-06 13:04   ` Juri Lelli
2023-10-03 14:09   ` Valentin Schneider

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=ZPhpfMjSiHVjQkTk@localhost.localdomain \
    --to=juri.lelli@redhat.com \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vschneid@redhat.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 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.