@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:)

LGTM

LGTM

In D57379#1314792, @jrtc27 wrote:

In D57379#1314791, @minsoochoo0122_proton.me wrote:

Back to my original question: How can we achieve this "special path" so processors with Zabha don't have severe performance impact?

Same as LSE on arm64

In D57379#1314786, @jrtc27 wrote:

In D57379#1314785, @minsoochoo0122_proton.me wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Just curious: do we have trampolines for sub-atomic operations at instruction level? Having them for Zabha or LDADD* would be great optimization opportunity.

I don't understand what your question means

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

In D57380#1314770, @zishun.yi.dev_gmail.com wrote:

In D57380#1314674, @minsoochoo0122_proton.me wrote:

I guess it's okay to merge this into D57381? See f115c0612131d8f939f6f357f57bdd85bd6a59de for amd64.

I think both are OK, see 698dbd66fed21e0acabf02a07be5080d016efa5c for arm64.

Both segments are placed in wrong lines. Please refer to sys/arm64/include/bus.h for correct order.

Rationale looks good. (Side note: RVA23 profile says Zabha will be mandatory in future RVA profiles)

I guess it's okay to merge this into D57381? See f115c0612131d8f939f6f357f57bdd85bd6a59de for amd64.

I would like to know what this is for. Code looks okay, but I wonder why we need these aliases. Could you elaborate more in the commit message and revision summary?

In D44456#1310982, @koinec_yahoo.co.jp wrote:

However, intelhfi driver needs to reference the number of CPU groups stored in the "cpu_group" structure. For this reason, I used the "cpu_grpup" structure in the location you pointed out, and also cached it in the intelhfi's instance structure.

@koinec_yahoo.co.jp Are you fine if I update the diff to match FreeBSD's man style? The content is fine, I just need to rephrase and move sections around for consistency with other man pages. You will still be the only person on the copyright notice and git author.

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