Date: Tue, 18 Sep 2007 16:55:22 -0700 From: Julian Elischer <julian@elischer.org> To: Sam Leffler <sam@errno.com> Cc: Andre Oppermann <andre@freebsd.org>, arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks Message-ID: <46F0656A.7030802@elischer.org> In-Reply-To: <46F05F88.5060809@errno.com> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F0656A.7030802>