[Top] [All Lists]

Re: [PATCH 2.6]: Make packet scheduler clock source configurable

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


Attachment: psched-bug_on_invalid_cycles.diff
Description: application/octect-stream

<Prev in Thread] Current Thread [Next in Thread>