Well The code itself I had up on machines for probably about 2 months. But then I switched over to Gleb’s changes here just recently .. which caused me all kinds of fun :)
I had to go back into Mercurial to pull back my changes.. I have had the resurrected changes running on my netflix machines for about 20 or so hours generating about anywhere from 14Gbps to 32Gbps depending on the machine type. I plan on waiting until tomorrow to sync it down into the NF code base. Note that if you do decide instead to roll back to the 10.x kern_timeout.c you will need to roll back a bunch of tcp changes as well that use the new async_drain() interface. I am game either way for you to proceed.. I will commit this current code to head as long as I hear no objections (from Gleb or others)…. R > On Jul 19, 2016, at 3:56 PM, Glen Barber <g...@freebsd.org> wrote: > > On Tue, Jul 19, 2016 at 03:46:54PM +0200, Randall Stewart wrote: >> Glen: >> >> My changes work.. I have them running in NF in at least 1/2 dozen machines. >> > > For how long? What are the uptimes on these machines? > > This is the blocker for 11.0-BETA2, and I don't want to see more > regressions being introduced at this point of the cycle. > > Glen > >> I am more than willing to commit them.. they actually are not much different >> than >> whats in stable 10.. though I don’t know if the async-drain was MFC’d >> there.. it >> needs to be in for TCP.. or else you will have yet another mess in that >> respect (TCP depends on ASYNC-drain). >> >> I can commit what I have.. if you like.. or not.. I really don’t care (I >> hate kern_timeout.c :-o) >> >> R >>> On Jul 19, 2016, at 2:25 PM, Glen Barber <g...@freebsd.org> wrote: >>> >>> On Tue, Jul 19, 2016 at 01:43:16PM +0200, Randall Stewart wrote: >>>> Gleb >>>> >>>> Ok >>>> >>>> I have now updated >>>> >>>> https://reviews.freebsd.org/D7135 >>>> >>>> You can take this or not… I really don’t care either way… (you are welcome >>>> to >>>> own the kern_timeout.c code I hate it) :-) >>>> >>>> Basically when you went off and re-factored kern_timeout.c I had worked in >>>> parallel on fixing >>>> the bugs you were seeing.. There were three distinct problems that I >>>> fixed… but then >>>> you had refactored the stop() routine.. and I thought ok.. thats fine. I >>>> had actually thought about >>>> doing something similar to what you did and was too chicken to poke that >>>> much at it.. it has >>>> always had a nasty habit of biting back when you make a lot of changes :-D >>>> >>>> I know my version has worked for quite some time in my testing so I >>>> brought it back. >>>> Complete with its 3 return codes (I only recently switched to your version >>>> and thus >>>> started having difficulties with leaks and crashes)…. >>>> >>>> You are welcome not to use this.. I know it works (it ran >>>> on a number of machines at NF last night.. and we will of course continue >>>> testing >>>> it as we finish our dev testing for the upcoming OCA software release).. >>>> For now >>>> this is what will be going out into the OCA’s at least :-) >>>> >>> >>> I'm honestly done with this topic, and at the point now where I'm >>> considering backing out all changes to callout(9) and related changes to >>> the state they were at in stable/10. >>> >>> This changes the KBI, and if it needs to be done, it needs to happen >>> now. We cannot wait for RC1 phase for this, and the amount of churn to >>> get things into a working state with the current implementation far >>> outweighs the benefit of the dangers. >>> >>> Glen >>> >> >> -------- >> Randall Stewart >> r...@netflix.com >> 803-317-4952 >> >> >> >> >> -------- Randall Stewart r...@netflix.com 803-317-4952 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
