> From: Scott Cheloha <scottchel...@gmail.com> > Date: Fri, 9 Oct 2020 13:03:05 -0500 > > Hey, > > > On Oct 7, 2020, at 8:49 PM, 内藤 祐一郎 <naito.yuich...@gmail.com> wrote: > > > > Hi. > > > > I'm looking forward to this patch is committed. > > Because this patch solves my problem about CARP timeout. > > > > IIJ, a company that I am working for, is using carp(4) on VMware ESXi hosts > > for VPN and web gateway services. > > > > One is master and the other is backup of carp(4). > > Active host sometimes failover to backup when the ESXi host gets high cpu > > usage. > > And also CPU ready of OpenBSD machine seems high average on ESXi monitor. > > > > High CPU ready machine delays sending carp advertisement for 3 or 4 seconds. > > It is enough to failover to backup. > > > > In my investigation, OpenBSD machine does not always get CPU under high CPU > > ready condition. > > Although it is needed for interrupt handler. > > The delay of calling hardclock() causes tick count up delay. > > One delay is small but will never be resolved. > > So total delay can reach 3 or 4 seconds while tick counts up to 100. > > The tickless patch can solve the delay. > > > > I have tried to adapt in_carp.c to the tickless attempt 2. > > Delay of carp advertisement reduced to about 2 seconds. > > I'm glad to hear it improves things. Thanks for testing it out. > > >> 2020/09/09 4:00、Mark Kettenis <mark.kette...@xs4all.nl>のメール: > >> The diff looks reasonable to me, but I'd like to discuss the path > >> forward with some people during the hackathon next week. > > > > Is there any discussion in the hackathon? > > Not that I heard. I wasn't at the hackathon, though. > > -- > > If I get an OK from someone I will commit what I have so far. > > Where do we stand? > > - The nitty gritty details in this commit -- the hashing, > the loops, and the basic algorithm -- haven't changed > in almost a year. I'm confident they work. > > - The commit itself doesn't change any behavior because no > existing timeouts are converted to use timeout_set_kclock(). > So we shouldn't see any regressions like last time until > someone deliberately changes an existing timeout to use the > kclock interfaces. > > The thing that needs to be decided is how to go about dragging > the rest of the tree into using the kclock timeout interfaces. > > - Should we keep a tick-based timeout interface? If so, > for how long? Linux kept theirs as a distinct interface. > FreeBSD discarded theirs. > > - Should we quietly reimplement timeout_add_sec(9), etc., > in terms of kclock timeouts or should we do a full-tree > API change to explicitly use timeout_in_nsec()? > > I don't think we can make such decisions without putting kclock > timeouts into the tree so people can use them. > > So, are you OK with this as-is? > > Anybody else?
I think this is good to go. ok kettenis@ Did briefly discuss with Theo during k2k20 and the consensus was it should go in after relase. Which is now!
