From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 00:09:07 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F269C16A41A; Wed, 19 Sep 2007 00:09:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id A327413C4B3; Wed, 19 Sep 2007 00:09:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8J07dkW093402 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 20:07:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 17:10:31 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Sam Leffler In-Reply-To: <46F05F88.5060809@errno.com> Message-ID: <20070918170545.X558@10.0.0.1> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Andre Oppermann , Julian Elischer Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 00:09:07 -0000 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 >