Date: Wed, 2 Oct 2019 17:05:23 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Sebastian Huber <sebastian.huber@embedded-brains.de> Cc: FreeBSD <freebsd-hackers@freebsd.org> Subject: Re: Make timehands count selectable at boottime? Message-ID: <20191002140523.GB44691@kib.kiev.ua> In-Reply-To: <c705f37c-a7d5-e656-f8af-e91de7f743d5@embedded-brains.de> References: <0d534569-504f-52c2-f09c-b977fe80843d@embedded-brains.de> <20191001143718.GU44691@kib.kiev.ua> <c705f37c-a7d5-e656-f8af-e91de7f743d5@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 02, 2019 at 08:48:33AM +0200, Sebastian Huber wrote: > On 01/10/2019 16:37, Konstantin Belousov wrote: > > On Tue, Oct 01, 2019 at 12:48:46PM +0200, Sebastian Huber wrote: > >> Hello, > >> > >> a recent commit made the timehands count selectable at boottime: > >> > >> https://reviews.freebsd.org/D21563 > >> > >> What was the reason for this change? > > > > See the followup thread on the svn-src@ list for this revision. > > Thanks for the hint. So, this change is related to the PPS handling and > the things which happen between a pps_capture() and pps_event(). Well, it is my reaction to the reports that there might be issues for some people. Apparently, the PPS issues were fixed by other means, see r352196. > > What I don't understand is why more timehands are a problem for the > consumer side. For example: > > void > binuptime(struct bintime *bt) > { > struct timehands *th; > u_int gen; > > do { > th = timehands; > gen = atomic_load_acq_int(&th->th_generation); > *bt = th->th_offset; > bintime_addx(bt, th->th_scale * tc_delta(th)); > atomic_thread_fence_acq(); > } while (gen == 0 || gen != th->th_generation); > } > > With more timehands the time frame in which th->th_generation remains > constant is longer the more timehands you have. So, it is less likely > that you have to execute the loop body twice. The count of timehands is > limited by the timecounter frequency and mask, and the hz configuration. And then the timehands you are looking at might be more stale. Ideally we would use one timehands, making the readers spin while update is done, but the fear is that the spin is too long for SMP, and that UP would suffer up to deadlock.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191002140523.GB44691>