Date:	Tue, 19 May 2009 11:46:58 +0200
From:	<Tero.Kristo@...ia.com>
To:	<dada1@...mosbay.com>
CC:	<netdev@...r.kernel.org>
Subject: RE: Network stack timer hacks for power saving

 

>-----Original Message-----
>From: ext Eric Dumazet [mailto:dada1@...mosbay.com] 
>Sent: 19 May, 2009 12:04
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: netdev@...r.kernel.org
>Subject: Re: Network stack timer hacks for power saving
>
>Tero.Kristo@...ia.com a écrit :
>> Hi,
>> 
>> I have been looking at network stack timer optimization for power 
>> saving in embedded ARM environment, basically trying to 
>avoid as many 
>> wakeups as possible. I have changed several timers in the network 
>> stack into deferred ones, i.e. they do not wake up the 
>device from low 
>> power modes but instead they are deferred until next wakeup 
>from some 
>> other source, like another (non-deferred) timer or some I/O. 
>Attached 
>> a patch about the changes I've done, is something like this safe to 
>> do?
>> 
>> -Tero
>
>Hi Tero
>

Hi Eric,

Thanks for comments. Also, I think I need to make one clarification here, I am not proposing these changes to be made into linux network stack, at least not as such because I am aware that these might cause some problems on some systems. If something like this would be merged, I think this should be added behind a kernel config option.

>
>When tcp communications are active, we setup a timer for 
>*every* frame we receive or we send. These timers wont be 
>deferrable anyway.
>
>delaying one wakeup every 60 seconds (if I take your 
>net/ipv4/route.c change) wont change that much power savings, 
>or did I missed something ?

No, this won't change it that much, but it still affects a bit. Also, if everybody thinks that a 1 minute timer does not matter too much, we soon have 60 timers expiring once a minute and can basically cause a wakeup from low power modes every second in the worst case.

>
>On big routers, we need to set ip_rt_gc_interval from 60 
>seconds to one second, in order to perform an effective 
>garbage collection.
>
>So, if we use a deferred timer and :
>
>schedule_delayed_work(&expires_work, HZ);
>
>How many times worker will be started every minute ?

I think big routers do not enter any low power states, due to heavy network traffic keeping them busy. Even if they do enter low power mode, I guess network HW will basically wake them up rather quickly causing the delayed work to be executed approximately around the time (or probably exactly at the time) it was scheduled. I might be wrong here, as I do not really know too much about network router power management.

Here is some data I grabbed from /proc/timer_stats before doing these changes (just added the network stack stuff here and calculated expiry rates.) I already changed most of the timers to deferrable in this sample, and also made a hack to show workqueues properly. Device was basically just idling during this measurement, not doing any frequent net communication.

Timer Stats Version: v0.2
Sample period: 59672.362 s
7455D,     1 swapper          neigh_table_init_no_netlink (neigh_periodic_timer) [neighbour.c, rate 1 per 8s]
  995,     0 workqueue        queue_delayed_work (rt_worker_func) [route.c, rate 1 per min]
 498D,     1 swapper          inet_initpeers (peer_check_expire) [inetpeer.c, rate 1 per 2 min]
  99D,     1 swapper          flow_cache_init (flow_cache_new_hashrnd) [flow.c, rate 1 per 10 min]
  99D,     1 swapper          inet_frags_init (inet_frag_secret_rebuild) [inet_fragment.c, rate 1 per 10 min]

-Tero--
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