From: Arjan van de Ven <arjan@linux.intel.com>
To: Parag Warudkar <parag.warudkar@gmail.com>
Cc: "Kok, Auke" <auke-jan.h.kok@intel.com>,
Stephen Hemminger <shemminger@linux-foundation.org>,
netdev@vger.kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sky2: Use deferrable timer for watchdog
Date: Thu, 20 Dec 2007 21:04:12 +0100 [thread overview]
Message-ID: <476ACABC.4010503@linux.intel.com> (raw)
In-Reply-To: <82e4877d0712201200h7b994175u841d1efa047cefff@mail.gmail.com>
Parag Warudkar wrote:
> On Dec 20, 2007 2:22 PM, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>> ok, that's just bad and if there's no user-defineable limit to the deferral I
>> definately don't like this change.
>>
>> Can I safely assume that any irq will cause all deferred timers to run?
>
> I think even other causes for wakeup like process related ones will
> cause the CPU to go busy and run the timers.
> This, coupled with the fact that no one is yet able to reach 0 wakeups
> per second makes it pretty unlikely that deferrable timers will be
> deferred indefinitely.
0.8 is easy on single core today.
multicore just increases how idle you can be for a given core.
>
>> If this is the case then for e1000 this patch is still OK since the watchdog needs
>> to run (1) after a link up/down interrupt or (2) to update statistics. Those
>> statistics won't increase if there is no traffic of course...
>>
>
> I think it is reasonable for Network driver watchdogs to use a
> deferrable timer - if the machine is 100% IDLE there is no one needing
> the network to be up. If there is something running even on the other
> CPU - that is going to cause an IPI, reschedule, TLB invalidation etc.
> which will make it very likely in practice that each CPU will be
> interrupted in reasonable amount of time.
this is not correct; many machines are idle waiting for network data. Think of webservers...
>
> Of course there are theoretical cases where we could land into a
> situation where a CPU in a multiprocessor machine is IDLE infinitely
> and that causes the watchdog that happens to be bound to run on the
> same CPU to not run. To take care of these unlikely cases I think the
> timer mechanism should have a reasonable limit on how long a CPU can
> go IDLE if there are deferrable timers.
how about something else instead: a timer mechanism that takes a range instead..
that at least has defined semantics; the deferrable semantics really are "indefinite".
Lets keep at least the semantics clear and clean.
next prev parent reply other threads:[~2007-12-20 20:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 1:13 [PATCH] sky2: Use deferrable timer for watchdog Parag Warudkar
2007-12-20 17:16 ` Stephen Hemminger
[not found] ` <823114761-1198171803-cardhu_decombobulator_blackberry.rim.net-937108990-@bxe019.bisx.prod.on.blackberry>
2007-12-20 17:51 ` Stephen Hemminger
2007-12-20 18:05 ` Parag Warudkar
2007-12-20 19:09 ` Kok, Auke
2007-12-20 19:11 ` Arjan van de Ven
2007-12-20 19:22 ` Kok, Auke
2007-12-20 19:42 ` Arjan van de Ven
2007-12-20 20:00 ` Parag Warudkar
2007-12-20 20:04 ` Arjan van de Ven [this message]
2007-12-20 20:36 ` Parag Warudkar
2007-12-20 21:08 ` Stephen Hemminger
2007-12-20 21:24 ` Kok, Auke
2007-12-20 20:17 ` Krzysztof Oledzki
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=476ACABC.4010503@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=auke-jan.h.kok@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=parag.warudkar@gmail.com \
--cc=shemminger@linux-foundation.org \
/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.