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

[Julian Elischer]

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.

but it still needs to work on systems with high hz values.

> 
>    Sam