64bit ticks, was Re: Changing p_swtime and td_slptime to ticks

[Jeff Roberson]

On Tue, 18 Sep 2007, Sam Leffler wrote:

> Jeff Roberson wrote:
>> On Tue, 18 Sep 2007, Jeff Roberson wrote:
>> 
>>> On Tue, 18 Sep 2007, Andre Oppermann wrote:
>>> 
>>>> Jeff Roberson wrote:
>>>>> On Mon, 17 Sep 2007, Julian Elischer wrote:
>>>>> 
>>>>>> Jeff Roberson wrote:
>>>>>>> Enclosed is a patch that fixes swapping with ULE.  ULE has never 
>>>>>>> properly set p_swtime and td_slptime which are used by the 
>>>>>>> swapout/swapin code to select the appropriate thread to swap.
>>>>>> 
>>>>>> I have not looked at in the depth required, but 2 points that I was 
>>>>>> unable
>>>>>> to check to my satisfaction before I got called away for work....
>>>>>> 
>>>>>> 1/ the source of the ticks is a monotonically increasing count that 
>>>>>> never
>>>>>> goes backwards or changes?
>>>>> 
>>>>> ticks is incremented each time hardclock() is called.  That's it.
>>>>> 
>>>>>> 
>>>>>> 2/ nothing that used to be accounted in seconds becomes accounted for 
>>>>>> in ticks?
>>>>> 
>>>>> I scale back to seconds where it is required.  Really I think ticks 
>>>>> would be the better metric in vm_glue.c but didn't want to make any 
>>>>> drastic changes.
>>>> 
>>>> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable
>>>> short uptime.  You have to make sure that your code handles that
>>>> correctly or you run into lots of strange effects which are almost
>>>> impossible to reproduce.  In TCP we've got bitten by that.
>>> 
>>> Thanks Andre, this is a good point.  For the td_slptime I don't think it's 
>>> of practical concern.  However, for swtime I think I will convert it then 
>>> to seconds from boot.
>> 
>> Is there a good reason for not making ticks 64bit?  math involving this 
>> value is relatively infrequent.  Bruce?  Any comments?  It'd sure let us 
>> forget all of these counter wrapping problems.
>
> ticks is used a lot.  I'd rather set hz back to 100 by default.  This 
> approach is a perfect example of ignoring low-end platforms.

Well there are certainly competing design goals and tradeoffs must be 
made.  In this particular case, I did consider the impact to 32bit 
platforms.  However, many people looking at real-time like platforms want 
even higher hz, so the solution must scale to both ends.

I believe we rarely do division or multiplication of ticks.  Emulated 
64bit adds and loads are not that expensive.  In fact, I don't see any 
division in kern/.  Perhaps you could try it on one of your embedded 
platforms and see if there is a measurable difference?  I suspect there 
will not be any.

Thanks,
Jeff

>
>   Sam
>