lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <877ib60vtz.fsf@vnet.ibm.com>
Date:	Mon, 28 Jul 2008 19:20:24 +0200
From:	Andreas Arnez <arnez@...t.ibm.com>
To:	netdev@...r.kernel.org
Subject: ksoftirqd doesn't really become active

While testing with arpflood, I stumbled across what looks like a
general flaw in the softirq processing: softirqs were keeping one CPU
busy; only 1% of this CPU capacity was left to other applications.
But still ksoftirqd didn't get scheduled much, most of the time
softirqs were processed in the context of irq_exit.  Hence the
scheduler didn't really influence the balancing between softirq
processing and other tasks, as probably intended.  This looks like a
general flaw which should affect every platform in one way or the
other.

Here's what seems to happen: an arp storm leads to the NAPI activating
softirqs all the time.  After 10 softirqs in a row the softirq
processing is suspended and ksoftirqd is woken up.  Now the scheduler
influences the remaining time until the next interrupt, after which 10
softirqs are processed in the context of irq_exit again.

Let
  s = average time spent on processing 10 softirqs;
  t = average time distance between hardirqs

If hardirqs come in regularly, then this CPU spends
ca. s/(t+t*int(s/t)) of its time on softirq processing in irq_exit
context:

                    s
   _________________/\________________
  /                                   \
  |=============|=============|=======>-----|
  \_____________/
         t

Once s approaches or exceeds t, the CPU is at least 50% busy
processing softirqs, regardless of the scheduler's decisions.

What are useful ways to increase the scheduler's influence?  One way
might be to suspend softirq processing in irq_exit context as long as
ksoftirqd feels responsible.  I made a test with a quick hack, and
this looks promising.  Are there other suggestions?  Or should the
whole issue be dealt with in a completely different way?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ