svn commit: r302998 - head/sys/kern

[Randall Stewart]

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 <gjb at 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 <gjb at 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
>> rrs at netflix.com
>> 803-317-4952
>> 
>> 
>> 
>> 
>> 

--------
Randall Stewart
rrs at netflix.com
803-317-4952