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

[Jeff Roberson]

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.

Thanks,
Jeff

>
> Jeff
>
>> 
>> -- 
>> Andre
>> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>