All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Levin Alexander <alexander.levin@verizon.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.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>,
	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 1/2] softirq: Account time and iteration stats per vector
Date: Fri, 12 Jan 2018 15:34:49 +0100	[thread overview]
Message-ID: <20180112143448.GA1950@lerouge> (raw)
In-Reply-To: <CANn89iKbJ6XABv291URQCipDOgNzYpHmUVi6FsPSTeYJXMdaKA@mail.gmail.com>

On Thu, Jan 11, 2018 at 10:22:58PM -0800, Eric Dumazet wrote:
> >  asmlinkage __visible void __softirq_entry __do_softirq(void)
> >  {
> > -       unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
> > +       struct softirq_stat *sstat = this_cpu_ptr(&softirq_stat_cpu);
> >         unsigned long old_flags = current->flags;
> > -       int max_restart = MAX_SOFTIRQ_RESTART;
> >         struct softirq_action *h;
> >         bool in_hardirq;
> > -       __u32 pending;
> > +       __u32 pending, overrun = 0;
> >         int softirq_bit;
> >
> >         /*
> > @@ -262,6 +273,7 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
> >         __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
> >         in_hardirq = lockdep_softirq_start();
> >
> > +       memzero_explicit(sstat, sizeof(*sstat));
> 
> If you clear sstat here, it means it does not need to be a per cpu
> variable, but an automatic one (defined on the stack)

That's right. But I thought it was bit large for the stack:

      struct {
          u64 time;
	  u64 count;
      } [NR_SOFTIRQS]

although arguably we are either using softirq stack or a fresh task one.

> 
> I presume we need a per cpu var to track cpu usage on last time window.
> 
> ( typical case of 99,000 IRQ per second, one packet delivered per IRQ,
> 10 usec spent per packet)

So should I account, like, per vector stats in a jiffy window for example? And apply
the limits on top of that?

> 
> 
> 
> >  restart:
> >         /* Reset the pending bitmask before enabling irqs */
> >         set_softirq_pending(0);
> > @@ -271,8 +283,10 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
> >         h = softirq_vec;
> >
> >         while ((softirq_bit = ffs(pending))) {
> > +               struct vector_stat *vstat;
> >                 unsigned int vec_nr;
> >                 int prev_count;
> > +               u64 startime;
> >
> >                 h += softirq_bit - 1;
> >
> > @@ -280,10 +294,18 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
> >                 prev_count = preempt_count();
> >
> >                 kstat_incr_softirqs_this_cpu(vec_nr);
> > +               vstat = &sstat->stat[vec_nr];
> >
> >                 trace_softirq_entry(vec_nr);
> > +               startime = local_clock();
> >                 h->action(h);
> > +               vstat->time += local_clock() - startime;
> 
> You might store local_clock() in a variable, so that we do not call
> local_clock() two times per ->action() called.

So you mean I keep the second local_clock() call for the next first call in the while
iteration, right? Yep that sounds possible.

> 
> 
> > +               vstat->count++;
> >                 trace_softirq_exit(vec_nr);
> > +
> > +               if (vstat->time > MAX_SOFTIRQ_TIME || vstat->count > MAX_SOFTIRQ_RESTART)
> 
> If we trust local_clock() to be precise enough, we do not need to
> track vstat->count anymore.

That's what I was thinking. Should I keep MAX_SOFTIRQ_TIME to 2 ms BTW? It looks a bit long
to me.

Thanks.

  reply	other threads:[~2018-01-12 14:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12  5:35 [RFC PATCH 0/2] softirq: Per vector threading Frederic Weisbecker
2018-01-12  5:35 ` [RFC PATCH 1/2] softirq: Account time and iteration stats per vector Frederic Weisbecker
2018-01-12  6:22   ` Eric Dumazet
2018-01-12 14:34     ` Frederic Weisbecker [this message]
2018-01-12 18:12       ` Linus Torvalds
2018-01-12 18:54         ` Frederic Weisbecker
2018-01-12  5:35 ` [RFC PATCH 2/2] softirq: Per vector thread deferment Frederic Weisbecker
2018-01-12  6:27   ` Frederic Weisbecker
2018-01-12  9:07   ` Paolo Abeni
2018-01-12 14:56     ` Frederic Weisbecker

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=20180112143448.GA1950@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=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.