From: Andrew Morton <akpm@linux-foundation.org> Date: 2007-05-30 17:59:54
On Tue, 29 May 2007 11:01:13 -0700
Venki Pallipadi [off-list ref] wrote:
quoted hunk
round_jiffies for net dev watchdog timer.
Signed-off-by: Venkatesh Pallipadi <redacted>
Index: linux-2.6.22-rc-mm/net/sched/sch_generic.c
===================================================================
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
From: Stephen Hemminger <hidden> Date: 2007-05-30 18:32:36
On Wed, 30 May 2007 10:59:36 -0700
Andrew Morton [off-list ref] wrote:
On Tue, 29 May 2007 11:01:13 -0700
Venki Pallipadi [off-list ref] wrote:
quoted
round_jiffies for net dev watchdog timer.
Signed-off-by: Venkatesh Pallipadi <redacted>
Index: linux-2.6.22-rc-mm/net/sched/sch_generic.c
===================================================================
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
--
Stephen Hemminger [off-list ref]
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree. Doing a mod_timer or hrtimer_forward to push forward may add to the
complexity depending on how often TX happens.
Are the drivers really worried about exact timeouts here? Can we use rounding
for the timers that are more than a second, at least?
Thanks,
Venki
From: Patrick McHardy <hidden> Date: 2007-05-30 19:33:21
Venki Pallipadi wrote:
On Wed, May 30, 2007 at 08:42:32PM +0200, Patrick McHardy wrote:
quoted
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree. Doing a mod_timer or hrtimer_forward to push forward may add to the
complexity depending on how often TX happens.
Are the drivers really worried about exact timeouts here?
Just guessing, but I don't think they are, after all timers can be late.
Can we use rounding for the timers that are more than a second, at least?
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.
I hope I could atleast highlight the issue here despite the cookie-cutter
patch..
On a totally idle system I have something like 85 wakeups for every 5 seconds
which I am trying to reduce (to reduce the power consumption and increase
battery life. And 1 interrupt out of 85 happens to be netdev watchdog timer.
Thanks,
Venki
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.
@@ -203,7 +203,11 @@ static void dev_watchdog(unsigned long adev->name);dev->tx_timeout(dev);}-if(!mod_timer(&dev->watchdog_timer,round_jiffies(jiffies+dev->watchdog_timeo)))++if(!mod_timer(&dev->watchdog_timer,+dev->watchdog_timeo>2*HZ+?round_jiffies(jiffies+dev->watchdog_timeo)+:jiffies+dev->watchdog_timeo))dev_hold(dev);}}
If this does not work:
Another option is to use 'deferrable timer' here which will be called at
same as before time when CPU is busy and on idle CPU it will be delayed until
CPU comes out of idle due to any other events.
Thanks,
Venki
if (dev->tx_timeout) {
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = 5*HZ;
- if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
+ round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
Please cc netdev on net patches.
Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
then they will get one second, which is grossly different.
And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
significant, too.
Alternatively, we could change to a timer that is pushed forward after each
TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
never run in normal case.
It seems wasteful to add per-packet overhead for tx timeouts, which
should be an exception. Do drivers really care about the exact
timeout value? Compared to a packet transmission time its incredibly
long anyways ..
I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.
What are you agreeing with, Dave?
Are you agreeing that "it seems wasteful to add per-packet overhead"?
This patch is not doing that.
A quick grep shows that most things are using multi-second timeouts
here. Of the ones that aren't, a number are using .4s, and many more
aren't even in units of HZ. Makes me wonder if the various boards
using 50ms are being overzealous.
--
Mathematics is the supreme nostalgia of our time.
If this does not work:
Another option is to use 'deferrable timer' here which will be called at
same as before time when CPU is busy and on idle CPU it will be delayed until
CPU comes out of idle due to any other events.
That would sound like a good idea here and at least power wise
it should be nearly free
-Andi