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_MIN to PRI_MAX_TIMESHARE and PRI_MIN_TIMESHARE to PRI_MIN_TIMESHARE + PRIO_MAX for nice-adjust process makes sense as it only takes 40 levels or so. (Side note: min and max for PRI and PRIO have opposite meanings, so it's kinda confusing here...)

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?

LGTM

• hardware.adoc: remove redundant LF at end of file
• hardware.adoc: update powerpc64 entries

In D57102#1308683, @kbowling wrote:

Under QEMU I would probably say "pSeries (PAPR)" just because qemu refers to that name still for launch.

And under IBM, which should be kept, with the bullet point: PAPR (native, LPAR, PowerVM)

In D57102#1308680, @kbowling wrote:

PowerVM is "just" an I/O server, the device model is always PAPR for "bare metal", LPAR, and PowerVM. This is the traditional OpenFirmware derived interface.

PowerNV is a separate, clean break, open source firmware available on some Power7+ systems, notably the Raptor stuff and qemu.

The original could mean PowerVM, but that's not "hardware" so that shouldn't on this note although PowerVM is pretty consistent across different Power servers (unlike x86 and arm).

I wasn't sure what "IBM: pSeries VM" meant, so I'm making an assumption here that it means QEMU pSeries.

Thanks, here are some reviews:

• total_capacity should have type hmp_capacity_t
• hmp_capacity_t is now uint32_t since total_capacity will overflow when there are 64 or more cores. hmp_score_t has also changed to uint32_t to reflect the change.

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

In D56546#1306730, @minsoochoo0122_proton.me wrote:

• Remove dynamic and throttle flags as they are not needed anymore

Thank you very much for the improvements.
Is it possible to retain the flag field and the definition of the "Throttled" flag?

If the intention behind removing it is that it might not be immediately used in the ULE scheduler, I understand the reasoning. I am currently learning about the ULE scheduler while testing intelhfi. Since ULE focuses on distributing loads to the lowest-load CPUs while remaining cache-aware, I agree that the Throttled flag isn't strictly necessary for ULE itself.

However, I view HMP(4) as a forward-looking mechanism designed to share scores across heterogeneous multicore architectures, rather than something optimized solely for the ULE scheduler. Also, considering that the Intel Hardware Feedback Interface defines a "Throttled" state, I assume this flag was initially introduced with Arm architecture development in mind.
Therefore, notification of the "Throttled" state could become essential in the future for managing heterogeneous multicore environments. For this reason, I would like to request keeping the Throttled state configurable rather than removing it.

• reflect recent changes to man page

• Print none in active provider sysctl when provider isn't selected

• Remove dynamic and throttle flags as they are not needed anymore
• Add hmp_lowest_capacity_cpu()

Abandoned with D56250