64bit ticks, was Re: Changing p_swtime and td_slptime to ticks
Sam Leffler
sam at errno.com
Tue Sep 18 17:33:49 PDT 2007
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.
Sam
More information about the freebsd-arch
mailing list