As @markj said, while here, please include sys/assert.h explicitly. It is already due because of sched_userret() above.

Currently reviewing the update.

I mentioned on the mailing list thread that I made it a minimal change to avoid interfering with future MFCs and planned to add the changes you proposed after the previous versions go EOL. But perhaps that's excessively conservative.

Yes, please (for 15).

New round of review. I think I have looked at all the changes now, but may do an additional quick check pass tomorrow.

In D45569#1039834, @theraven wrote:

I’ve seen that number a lot, but no source for it. First, I would say that I don’t care about 99% of users for something like this, I care about 99% of *first time* users. This is confusing only the first time that you run the installer. The second time, you’re already somewhat invested in FreeBSD, the important thing is not to put people off before they even get to first boot.

Well, I'm almost done, but not completely (I need to finish reviewing unionfs_lock() and the lines below it). Here's a new round of comments/notes/requests.

Also in favor of this, as I'm guessing that installation alongside some Windows is a marginal use-case for FreeBSD.

Some manpage nit, but after that should be good to go.

In D45545#1039132, @imp wrote:

I don't think this is good policy, as is. I like being able to delegate to the jails, but I thing it's really bad to conflate settime and adjtime. The two are different, though related, things.

Thanks for this important cleanup on the road to the new unionfs!

Oh, you're right, I hadn't checked for the PRIV_NETINET_* ones. I think that how these are handled makes sense.

Great. I have personally wanted that for a while.

Sorry, I've lagged on this one. I'll review it on Monday.

In D45390#1037328, @jeff wrote:

Moving by 4 each tick will require you to evaluate 4 run queues each time you want to advance.

I agree this may improve affinity in some cases, but at the same time we don't really know when the next thread on the queue is to run. Not stealing in this case also amounts to slightly violating the expected execution ordering and fairness.

It does steal in that case though, it will just prefer the second thread over the first. We don't permanently skip the first thread.

In D45390#1036063, @jeff wrote:

The runq index only moves at a rate slower than once per-tick when the system is very overloaded. This is how ULE implements priority decay. The difference in priority determines how many slices the lower (better) priority task will get for each slice the worse priority task will get.

In D45388#1035721, @mav wrote:

I suspect that first thread was skipped to avoid stealing a thread that was just scheduled to a CPU, but was unable to run yet.

In D39270#1036114, @imp wrote:

FreeBSD version bump?

In D45418#1036100, @imp wrote:

Simplify the #ifdefs, even though this is a bit longer than the prior
expressions.

In D45418#1036068, @mohd.akram_outlook.com wrote:

Is the second ifdef change correct (or needed)? I think both clauses will get ifdef'd out this way if CLOCK_BOOTTIME == CLOCK_MONOTONIC.

I guess this has to be upstreamed (not familiar with WPA).

In D39270#1035983, @imp wrote:

I'm convinced this is good. I'll push it in.

In D45390#1035791, @jeff wrote:

There is one thing the original code author intended that we will have to validate. The relative impact of nice levels depends on their distance in the runq. ridx/idx (I'm not sure why they were renamed in one diff) march forward at a fixed rate in real time. Changing the number of queues and priorities changes that rate. I believe it will have the effect of increasing the impact of nice. We may need to change the way nice values are scaled to priorities to compensate.

In D45390#1035772, @mav wrote:

This is sure the easiest (least invasive answer) answer, but does it make it the right answer? Simply doing nothing here could expose the original code author's ideas. There could be some rationale that you are dropping. It would be nice to look what was it, unless you've done it already.

Incorporate suggestions.

In D45387#1035485, @imp wrote:

Hopefully this is actually multiple commits. This change looks on its surface too large to review due to the 12 different things going on. .

Ok, I had missed reviews D45380 and D45381, which mostly answer my question.

Hi Seigo,