Date: Fri, 4 Jan 2013 03:54:55 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alexander Motin <mav@FreeBSD.org> Cc: Davide Italiano <davide@FreeBSD.org>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Marius Strobl <marius@alchemy.franken.de>, FreeBSD Current <freebsd-current@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au>, freebsd-arch@FreeBSD.org, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: [RFC/RFT] calloutng Message-ID: <20130104034917.O1929@besplex.bde.org> In-Reply-To: <50E5ADE1.4020104@FreeBSD.org> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn%2Buqv7w@mail.gmail.com> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> <50E4A902.4050307@FreeBSD.org> <20130103232413.O947@besplex.bde.org> <50E5ADE1.4020104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jan 2013, Alexander Motin wrote: > On 03.01.2013 16:45, Bruce Evans wrote: >> On Wed, 2 Jan 2013, Alexander Motin wrote: >>> More important for scheduling fairness thread's CPU percentage is also >>> based on hardclock() and hiding from it was trivial before, since all >>> sleep primitives were strictly aligned to hardclock(). Now it is >>> slightly less trivial, since this alignment was removed and user-level >>> APIs provide no easy way to enforce it. >> >> %cpu is actually based on statclock(), and not even used for scheduling. > > May be for SCHED_4BSD, but not for SCHED_ULE. In SCHED_ULE both %cpu and > thread priority based on the same ts_ticks counter, that is based on > hardclock() as time source. Interactivity calculation uses alike logic and > uses the same time source. Hmm. I missed this because it hacks on the 'ticks' global. It is clearer in intermediate versions which use the scheduler API sched_tick(), which is the hardclock analogue of sched_clock() for statclock. sched_tick() is now bogus since it is null for all schedulers. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130104034917.O1929>