| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 2.6]: Make packet scheduler clock source configurable |
| From: | Patrick McHardy <kaber@xxxxxxxxx> |
| Date: | Fri, 23 Jul 2004 02:52:32 +0200 |
| Cc: | shemminger@xxxxxxxx, netdev@xxxxxxxxxxx, devik@xxxxxx |
| In-reply-to: | <20040722171752.341d2476.davem@xxxxxxxxxx> |
| References: | <40F34740.5040100@xxxxxxxxx> <1107.63.170.215.71.1089689716.squirrel@xxxxxxxxxxxx> <20040712205037.573411c0.davem@xxxxxxxxxx> <40F4862D.3070802@xxxxxxxxx> <40F4AC8B.40706@xxxxxxxxx> <20040721143110.4ab944bf.davem@xxxxxxxxxx> <41004F76.1080807@xxxxxxxxx> <20040722171752.341d2476.davem@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 |
David S. Miller wrote: It needs to increment at slightly above 1Mhz, otherwise delay will be zero after this division and everything will fall apart: delay /= rdelay.I see. I know for a fact that sparc64 meets this criterion, and I'm pretty sure ppc64 does too. I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can be used. I'm not sure if the frequency of all ppcs is high enough, so I won't add support for them. We could bug check this in psched calibration, in fact I think we should. Done by this patch. I used BUG_ON instead of just printing a warning because using packet schedulers after this error will cause a division by zero. Regards Patrick
|
| Previous by Date: | Re: [PATCH 2.6 2/2]: Use get_cycles for PSCHED_CPU clock source, David S. Miller |
|---|---|
| Next by Date: | Re: [PATCH 2.6]: Make packet scheduler clock source configurable, Patrick McHardy |
| Previous by Thread: | Re: [PATCH 2.6]: Make packet scheduler clock source configurable, David S. Miller |
| Next by Thread: | Re: [PATCH 2.6]: Make packet scheduler clock source configurable, Patrick McHardy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |