Re: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock - Russell King

From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: anish singh <anish198519851985@gmail.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	linux-kernel-mail <linux-kernel@vger.kernel.org>,
	arm@kernel.org, John Stultz <john.stultz@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock
Date: Mon, 10 Jun 2013 17:08:03 +0100	[thread overview]
Message-ID: <20130610160803.GW18614@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAK7N6vqao-O4hTLCNatu3LVC38OFR+L8MxZCc-gi1fikBSdYYA@mail.gmail.com>

On Mon, Jun 10, 2013 at 09:31:21PM +0530, anish singh wrote:
> On Mon, Jun 10, 2013 at 9:08 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> Least I can do is to say "Thanks".
> > On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote:
> >> Probably a trivial question.I was wondering why this particular requirement
> >> exists in the first place.I looked into this commit 112f38a4a3 but couldn't
> >> gather the reason.
> >
> > You're looking at a commit introducing an implementation.  The requirement
> > isn't driven by the implementation.  It's driven by the code and the maths
> > in the core scheduler, and its been a requirement for years.
> >
> > sched_clock() needs to be monotonic, and needs to wrap at 64-bit, because
> > calculations are done by comparing the difference of two 64-bit values
> > returned from this function.
> 
> Yes, and this is the question.If it is 32 bit then also it can overflow but
> it will happen relatively fast.So I guess that is the reason why we use 64 bit
> and this will avoid recalculations for recalibration.

And that's why 112f38a4a3 is there - to ensure that we extend a 32-bit
or smaller counter all the way up to the full 64-bits.  This replaces
the previous generation code which only extended it to 63-bits.  Problems
were reported!

> > Let's take a trivial example - if you have a 16 bit counter, and you have
> > a value of 0xc000 ns, and next time you read it, it has value 0x0001 ns,
> > then what value do you end up with when you calculate the time passed
> > using 64-bit maths.
> >
> > That's 0x0000000000000001 - 0x000000000000c000.  The answer is a very big
> > number which is not the correct 16385.  This means that things like process
> > timeslice counting and scheduler fairness is compromised - I'd expect even
> 
> So you mean when counter overflows the scheduler doesn't handle it?

There is no handling of counter overflows at scheduler level because
the specification for sched_clock() is that this function _will_ return
a monotonically increasing 64-bit value from 0 to the maximum 64-bit
value.

The reason for this is that there are popular architectures around
which do this natively, so the powers that be do not want additional
useless code cluttering their architectures.