Address the three promised review points

Thanks! (Suggested by: olce appreciated.)

In D59406#1365004, @mchoo wrote:

schedcpu()'s call to decay_cpu() happens regardless of awake, that is, even sleeping threads are decayed for the first tick of ts_slptime.

Sorry if I made some modifications to what you sent me via email. I actually thought I was allowed to, as it isn't finalised yet and we're working through it together. I'm just trying to make sure we're not rushing things and that we're on the same page as we go along, for future maintenance and stuff we'd be working on together. I certainly don't mean to be rude or inattentive. Also, thank you for putting so much time and effort into reviewing everything, explaining things, and discussing it all with me, and being this much receptive and kind throughout. I really appreciate it.

In D59462#1365088, @kib wrote:

In D59462#1365021, @fuz wrote:

Oh yeah, using the archlevel framework sounds like a good idea! I didn't even think about that, as it's specific to libc. Other libm functions may profit in the future.

Do you have any notes about the updated patch?

BTW, I was not able to come up with a C expression that can be used to initialize the function table, so I resorted to filling it in assembler same as is done for strings.

Sure thing. I want to land it next week , after you and @olce test it.

Just waiting on portmgr approval now to make it official

FWIW when we did LB we were really worried about breaking software, and in hindsight we maybe should have just aligned REUSEPORT across a major FreeBSD version with Linux to minimize third party software adaptation. Think hard before adding yet another non-portable sockopt; the LB_CPU_CURRENT behavior sounds desirable unless there is some corner you see. So I agree with Gleb.

Changes, as requested:

Since proposed changes all happen under RSS, make Adrian the owner, but also subscribe other potentially interested parties.

Pardon naive quick question, before reading deeper into the proposal: any downsides with proposed behavior? Can it be on by default for SO_REUSEPORT_LB?

Any opinion if NOLOCK would be a better name than NULLLOCK?

On second thought, I'd like to test this on netflix workload before we commit

Yeah, sorry about the confusion.

That is the same as the mr issue.

This is revision-4. The previous diff was revision-3 (D58990?id=185468).

In D59449#1364566, @markj wrote:

I'd somewhat prefer to have less code when possible.

Use a separate variable called reduce_pos for the
reduction position, which is now calculated by the
NFS glue code, as suggested by Vinicius.

Not 100% confident, but that drm-kmod issue seems similar enough I think there's a decent chance this solves it. More testing would definitely be helpful