From: Frederic Weisbecker <frederic@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
LKML <linux-kernel@vger.kernel.org>,
Levin Alexander <alexander.levin@verizon.com>,
Peter Zijlstra <peterz@infradead.org>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Wanpeng Li <wanpeng.li@hotmail.com>,
Dmitry Safonov <dima@arista.com>,
Thomas Gleixner <tglx@linutronix.de>,
Eric Dumazet <edumazet@google.com>,
Radu Rendec <rrendec@arista.com>, Ingo Molnar <mingo@kernel.org>,
Stanislaw Gruszka <sgruszka@redhat.com>,
Paolo Abeni <pabeni@redhat.com>, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>
Subject: Re: [RFC PATCH 0/5] softirq: Per vector threading v2
Date: Thu, 18 Jan 2018 03:55:41 +0100 [thread overview]
Message-ID: <20180118025539.GA20310@lerouge> (raw)
In-Reply-To: <CA+55aFzojENpf+-fEhkNL_RaQbtC0FoB6x7DDXqZCScCOAUmQg@mail.gmail.com>
On Wed, Jan 17, 2018 at 03:56:43PM -0800, Linus Torvalds wrote:
> On Wed, Jan 17, 2018 at 10:07 AM, Frederic Weisbecker
> <frederic@kernel.org> wrote:
> >
> > I see, so you may want to test (possibly much) higher values of MAX_SOFTIRQ_RESTART,
> > such as 50 or 100.
>
> I suspect the "number of softiqs per jiffy" is hardly interesting at all.
>
> We used to allow up to 2mS or ten iterations per _invocation_, never
> mind per timer tick.
>
> I thought you were going to actally account for time, but I don't
> think you ended up doing that.
I did in the first version but then I thought you suggested that count per
jiffy. I probably misunderstood :)
>
> Maybe time isn't necessarily the thing to do, but just pure "count per
> jiffy" seems very bad.
Indeed, the more I think about it, the more doubts I have too. At least
I started to think that this metric alone is not enough.
>
> What I might suggest using instead:
>
> - do it by time. This may be too expensive, though. Keeping track of
> ns-level timing per invocation can be nasty.
Yeah I would like to avoid that if we can. I guess it's ok if it sums up
to rdtsc but I fear it's common to have a heavier version.
>
> - do it by "we got a new softirq event while handling another softirq
> event". That was our old count per invocation, except you could do it
> per softirq, and just allow *one* (ie keep a bitmask of "I've already
> handled this softirq", and if the restart results in it being
> triggered *again* you say "ok, I'll just move this to a workqueue"
That one is very tempting.
>
> - .. something else?
>
> I'd suggest trying the "if we get a new softirq event that we've
> already seen while we were already handling softirq events" thing.
> That should really take care of the networking case of "90% time spend
> in softirq handling during packet storms" thing. If we spend that much
> time on softirqs, we *will* get a new softirq while handling an old
> one occasionally.
Ok I'm going to try that for the v3.
Thanks.
next prev parent reply other threads:[~2018-01-18 2:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 4:40 [RFC PATCH 0/5] softirq: Per vector threading v2 Frederic Weisbecker
2018-01-16 4:40 ` [RFC PATCH 1/5] softirq: Account time and iteration stats per vector Frederic Weisbecker
2018-01-16 4:40 ` [RFC PATCH 2/5] softirq: Per vector deferment to workqueue Frederic Weisbecker
2018-01-16 4:40 ` [RFC PATCH 3/5] softirq: Defer to workqueue when rescheduling is needed Frederic Weisbecker
2018-01-16 4:40 ` [RFC PATCH 4/5] softirq: Replace ksoftirqd with workqueues entirely Frederic Weisbecker
2018-01-16 4:40 ` [RFC/OPTIONAL PATCH 5/5] softirq: Reset vector call counter before workqueue completion Frederic Weisbecker
2018-01-17 16:56 ` [RFC PATCH 0/5] softirq: Per vector threading v2 Mauro Carvalho Chehab
2018-01-17 18:07 ` Frederic Weisbecker
2018-01-17 23:56 ` Linus Torvalds
2018-01-18 2:55 ` Frederic Weisbecker [this message]
2018-01-18 3:09 ` Linus Torvalds
2018-01-18 4:09 ` Frederic Weisbecker
2018-01-18 12:44 ` Dmitry Safonov
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=20180118025539.GA20310@lerouge \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.levin@verizon.com \
--cc=davem@davemloft.net \
--cc=dima@arista.com \
--cc=edumazet@google.com \
--cc=hannes@stressinduktion.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@s-opensource.com \
--cc=mingo@kernel.org \
--cc=pabeni@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rrendec@arista.com \
--cc=sgruszka@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=wanpeng.li@hotmail.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.