Reflect @olce's suggestion

Duplicate of D59404

@jhb I need mentor approval.

• Update date
• Add mentor-mentee entry

Update date

Is this and D58507 subject to MFC?

Actually it works without "On " in the front

Update comment (83 columns)

In D58065#1332142, @olce wrote:

In D58065#1332040, @minsoochoo0122_proton.me wrote:

Since I don't have commit bit yet, could you push it for me? Thanks:)

Sure. With the minsoo.io address I presume?

Fit comment in one line (99 columns)

In D58065#1331883, @olce wrote:

Do you want me to commit that? Or can you with jhb@'s approval?

Add Suggested by: olce

Update commit message
Reflect @olce's suggestion

In D58000#1331427, @olce wrote:

Introducing ts_rqcpu actually makes ts_runq redundant, so please remove that last field, possibly adding helpers to get the corresponding runqueue/change the runqueue length variable, and renaming the global runq to global_runq so that you can introduce runq local variables (separate commit). With this, there is no case where memory consumption isn't improved by this whole change, for absolutely zero change in performance if I'm not mistaken (except for sched_4bsd_rem()'s access, but that looks negligible).

Thanks!

I would like to add bit more:

In D57829#1330688, @minsoochoo0122_proton.me wrote:

Wouldn't this clamp threads with different priorities to the same index (tdq->tdq_ts_deq_off - 1)?

Is there any way that we can ensure tdq_ts_deq_off is always behind tdq_ts_off + MODULO and replace the whole thing as MPASS() instead?

Wouldn't this clamp threads with different priorities to the same index (tdq->tdq_ts_deq_off - 1)?

For now I don't have enough time to visit this, so I'll take a look at this later. If I don't give any comment by Saturday evening, you can commit this.

I think this is okay. We now have plenty of timeshare priority levels, so preserving PRI_MAX_TIMESHARE - PRIO_MAX to PRI_MAX_TIMESHARE and PRI_MIN_TIMESHARE to PRI_MIN_TIMESHARE - PRIO_MIN for nice-adjust process makes sense as it only takes 40 levels or so.

LGTM. I didn't know this was from KSE times, but yes, we should let it go now.

Updated benchmark for amd64 16-CURRENT, both libc built from my local machine and tested on it

In D58002#1330171, @fuz wrote:

Oh is that the case for both? How did you select a debug build? If so it's kind of an apples to oranges comparison.

In D58002#1330056, @fuz wrote:

This sounds like a good idea for simplicity indeed.

However, the performance does suffer in the aligned case throughout the board.

Could you by chance test on arm64 where we do have a SIMD-based memcpy implementation?

Fix indent on flags

Benchmark results

update commit message (int -> u_int)

In D56546#1323249, @koinec_yahoo.co.jp wrote:

(This may not be the appropriate place to post this, but please forgive me as I don't know of any other suitable location.)

You can mark all my existing inline comments as done except for the module vs device driver one.

Fix missing hmp_capacity_t separation

In D44457#1317663, @koinec_yahoo.co.jp wrote:

In D44457#1310996, @minsoochoo0122_proton.me wrote:

Wait, could you add this to amd64/LINT as well?

Excuse me, I need some help.

Looking at sys/amd64/conf/LINT, it includes the NOTES file in the same directory.
And, as shown above, I've added intelhfi to the NOTES file.
Therefore, I believe this has already been done. Am I misunderstanding something?

LGTM. Optionally the commit message can have

Superseded by D57472 and D57473.

From 072f54bf9ff3fb544ae65649e723d5f846b53897,

This is why I want to have C23 in base, but it's not the right time yet... LGTM:)