linux-kernel - Re: [PATCH] e1000: Use deferrable timer for watchdog

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Dec 2007 17:35:01 -0500
From:	"Parag Warudkar" <parag.warudkar@...il.com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	"Arjan van de Ven" <arjan@...ux.intel.com>
Subject: Re: [PATCH] e1000: Use deferrable timer for watchdog

On Dec 19, 2007 4:38 PM, Kok, Auke <auke-jan.h.kok@...el.com> wrote:
> Parag Warudkar wrote:
> > On 12/19/07, Kok, Auke <auke-jan.h.kok@...el.com> wrote:
>
> why would this patch reduce wakeups even more than round_jiffies()? Does it make
> our ~2 second update interval not reliable? can you quantify "shows it reduces" ?
> Or timer only runs once every two seconds...

Without the patch - here is what powertop reports steady on my desktop -

Wakeups-from-idle per second :  8.5     interval: 1.9s
no ACPI power usage estimate available

Top causes for wakeups:
  28.6% (  4.0)     <kernel core> : clocksource_register (clocksource_watchdog)
  14.3% (  2.0)         automount : futex_wait (hrtimer_wakeup)
  14.3% (  2.0)              ntpd : do_setitimer (it_real_fn)
  14.3% (  2.0)           ntpdate : do_adjtimex (sync_cmos_clock)
   7.1% (  1.0)       <interrupt> : PS/2 keyboard/mouse/touchpad
   7.1% (  1.0)       <interrupt> : eth0
   7.1% (  1.0)                ip : e1000_intr_msi (e1000_watchdog)

$> stop network; rmmod e1000e
$> patch e1000e/netdev.c ; rebuild ; insmod
$> Wait for things to settle

With the patch here is what it shows steadily -

Wakeups-from-idle per second :  7.5     interval: 5.8s
no ACPI power usage estimate available

Top causes for wakeups:
  32.4% (  2.2)     <kernel core> : clocksource_register (clocksource_watchdog)
  17.6% (  1.2)              ntpd : do_setitimer (it_real_fn)
  14.7% (  1.0)           ntpdate : do_adjtimex (sync_cmos_clock)
   8.8% (  0.6)       <interrupt> : eth0
   5.9% (  0.4)          events/1 : __netdev_watchdog_up (dev_watchdog)
   5.9% (  0.4)     <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_   5.9% (  0.4)   <kernel module> :
neigh_table_init_no_netlink (neigh_periodic_timer)

So no longer e1000_watchdog is waking up the CPU for its own sake - it
still runs but when the CPU is already out of IDLE to run something
else that needs to be run undeferred.
Wakeups from IDLE are down by 1 - from 8.5 to 7.5 .

>
> maybe I just don't understand the effect of timer_set_deferrable() - we're already
> deferring it ourselves when we want to. If that is not working then I suggest that
> we fix that first instead of postponing the critical first run of the e1000
> watchdog task.

There is of course a difference between round_jiffies() and
timer_set_deferrable() if that's what you were referring to.
round_jiffies() will make the timer run at whatever rounded value no
matter if the CPU is already IDLE or not. Making the timer deferrable
makes it run only when the CPU is NOT IDLE - that is to say it is busy
running something else - another non-deferrable timer for instance.

>
> People in the datacenter really don't want to see more delays when bringing up
> link, and we get frequent calls about it already being long on gigabit (not even
> minding spanning tree). Adding 25% to that time isn't going to down very nicely
> with them.
>
Well but when the machine is coming up the CPU is not going to be IDLE
and your initial timer will likely run when it wants to - i.e.
deferable timers won't be deferred if the CPU is not IDLE.
On the other hand Data center people do care about power consumption
and they would much rather make sure they don't lose network links on
Production boxes - so a properly configured machine/network should not
need to bring up the link more than a small number of times if at all.
Lastly e1000 is also sold with many desktop machines (like mine) and
those people will surely appreciate lesser wakeups.

I don't have GigE connection where my desktop is located and with
100Mbps I don't notice any measurable delay in bringing up the link -
may be you could try with this patch and see exactly how longer if at
all it takes to bring up the link on a GigE connected machine.

Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/