fixed DSiGetLogicalProcessorInformationEx and LoadNumaInfo

[gabr42]

Summary by Bito

• This pull request introduces new functions to retrieve CPU affinity masks for both efficiency and performance cores, enhancing the ability to manage system resources effectively.
• A fix was applied to ensure the logical processor information function utilizes the correct buffer type, ensuring accurate data retrieval.
• This pull request introduces new functionality to retrieve extended logical processor information in the DSiWin32 module, adding new data structures and a function, DSiGetLogicalProcessorInfoEx.
• Overall, this pull request addresses logical processor information retrieval, introduces new functions for core affinity management, and includes bug fixes for accurate data handling.

[claude]

Pull Request Review: Fixed DSiGetLogicalProcessorInformationEx and LoadNumaInfo

Summary

This PR fixes issues with DSiGetLogicalProcessorInformationEx and LoadNUMAInfo, and adds support for E-core/P-core detection on Intel hybrid architectures. The changes include significant refactoring of processor information handling.

---

Code Quality and Best Practices

Positive aspects:

• Well-structured refactoring that simplifies the LoadNUMAInfo procedure in OtlCommon.pas
• Good separation of concerns with the new wrapper function DSiGetLogicalProcessorInfoEx
• Clear addition of version history entries
• Appropriate use of conditional compilation directives
• Proper memory management with try-finally blocks

Areas for improvement:

• Consider adding XML documentation comments for the new public functions (DSiGetSystemECoreAffinity, DSiGetSystemPCoreAffinity, etc.)
• The new type definitions could benefit from more detailed comments explaining their purpose

---

Potential Bugs and Issues

Critical Issue - Line 7685 in DSiWin32.pas:

for iGroup := 0 to High(pInfo.Processor.GroupMask) do
  pInfo.Processor.GroupMask[iGroup] := pInfo.Processor.GroupMask[iGroup];

This line assigns a value to itself, which is a no-op. It should likely copy from pBuffer.Processor.GroupMask[iGroup]:

pInfo.Processor.GroupMask[iGroup] := pBuffer.Processor.GroupMask[iGroup];

This is a critical bug that will result in uninitialized data in the GroupMask array.

Minor Issues:

1. Type signature mismatch: The function DSiGetLogicalProcessorInformationEx at line 2332 changes the Buffer parameter type from PSYSTEM_LOGICAL_PROCESSOR_INFORMATION to PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX, which is correct, but ensure all call sites are updated.

2. Error handling: In DSiGetLogicalProcessorInfoEx (line 7665), the function checks GetLastError after calling DSiGetLogicalProcessorInformationEx, but doesn't verify if Result is False before checking the error. Consider:

if (not Result) and (GetLastError = ERROR_INSUFFICIENT_BUFFER) then

3. Potential logic issue in E-core/P-core detection: Lines 5914-5917 and 5944-5947 have the same bit-shifting logic that seems to account for hyperthreading (Flags field), but the logic is somewhat cryptic. Consider adding a comment explaining:
   • What does Flags = 0 represent?
   • Why do we shift twice when Flags ≠ 0?

---

Performance Considerations

Good:

• Removal of manual buffer pointer arithmetic in favor of array indexing improves readability and safety
• The new approach with dynamic arrays is cleaner than raw pointer manipulation

Concerns:

1. Multiple array reallocations: In DSiGetLogicalProcessorInfoEx (line 7673), SetLength(info, Length(info) + 1) is called in a loop, which causes multiple memory reallocations. Consider pre-calculating the required size or using a temporary list structure, then converting to an array at the end.

2. Iterating in reverse: Lines 5910 and 5940 iterate from High(info) downto 0. While this might be intentional for bit ordering, consider adding a comment explaining why reverse iteration is necessary.

---

Security Concerns

Low Risk:

• Proper use of GetMem/FreeMem with exception handling
• No obvious buffer overflow risks due to use of dynamic arrays
• Appropriate bounds checking with High() function

Recommendations:

• The Move operations at lines 7689, 7691, and 7693 assume structure sizes match. Consider adding assertions or size checks for defense in depth.

---

Test Coverage

Concerns:

• No tests appear to be included with this PR
• The changes affect critical low-level processor detection functionality
• Given the bug found in line 7685, this strongly suggests insufficient testing

Recommendations:

1. Add unit tests for DSiGetLogicalProcessorInfoEx to verify correct data parsing
2. Add tests for the new E-core/P-core detection functions on both hybrid and non-hybrid CPUs
3. Verify LoadNUMAInfo works correctly on systems with multiple NUMA nodes
4. Test on systems without NUMA support to ensure CreateFakeNUMAInfo fallback works

---

Action Items

Must Fix:

• Fix the self-assignment bug at DSiWin32.pas:7685

Should Consider:

• Optimize array reallocation in DSiGetLogicalProcessorInfoEx
• Add error checking before GetLastError calls
• Add XML documentation for new public functions
• Add explanatory comments for bit-shifting logic in E-core/P-core detection
• Add unit tests covering the new functionality
• Consider adding size validation for Move operations

Testing Checklist:

• Test on systems with E-cores and P-cores (Intel 12th gen+)
• Test on traditional multi-core CPUs without hybrid architecture
• Test on systems with multiple NUMA nodes
• Test on systems with multiple processor groups (>64 cores)
• Test on systems without NUMA support

---

Overall Assessment

The refactoring improves code maintainability by replacing manual pointer arithmetic with cleaner array-based access. However, there is a critical bug in the GroupMask copying logic that must be fixed before merging. Additionally, test coverage should be added to prevent similar issues in the future.

The new E-core/P-core detection features are a valuable addition for modern Intel hybrid architectures, but would benefit from better documentation and testing.

[claude]

Pull Request Review

Thanks for this PR! I've reviewed the changes and have the following feedback:

✅ Positive Changes

1. Bug Fix - Correct Buffer Type: The fix to DSiGetLogicalProcessorInformationEx in line 2332 of DSiWin32.pas correctly changes the buffer parameter from PSYSTEM_LOGICAL_PROCESSOR_INFORMATION to PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX. This is an important type safety fix.

2. Improved Code Structure: The refactoring of LoadNUMAInfo (OtlCommon.pas:4360-4395) is much cleaner:

   • Eliminates manual pointer arithmetic with the array-based approach
   • Removes complex manual buffer management
   • More readable and maintainable code
   • Reduces the chance of memory corruption from incorrect pointer arithmetic

3. New Functionality: The addition of E-core/P-core detection functions (DSiGetSystemECoreAffinityMask, DSiGetSystemPCoreAffinityMask) provides valuable functionality for modern hybrid CPU architectures.

4. Extended API Support: Adding new processor relationship types (RelationProcessorDie, RelationNumaNodeEx, RelationProcessorModule) aligns with newer Windows API capabilities.

---

⚠️ Issues & Concerns

1. Critical: Missing Error Handling (DSiWin32.pas:7664-7702)

The new DSiGetLogicalProcessorInfoEx function lacks proper error handling:

bufSize := 0;
Result := DSiGetLogicalProcessorInformationEx(relationshipType, nil, bufSize);
if (not Result) and (GetLastError = ERROR_INSUFFICIENT_BUFFER) then begin

Problem: If the first call fails with an error OTHER than ERROR_INSUFFICIENT_BUFFER, the function silently returns False without setting info to an empty array first. This could leave info in an undefined state.

Recommendation: Add explicit error handling similar to the pattern in DSiGetLogicalProcessorInfo:

SetLength(info, 0); // Initialize at the start
bufSize := 0;
Result := DSiGetLogicalProcessorInformationEx(relationshipType, nil, bufSize);

2. Potential Logic Issue: Processor.Flags Interpretation (DSiWin32.pas:5914, 5944)

The code uses Processor.Flags = 0 to detect "normal core" vs hyperthreaded:

if info[iProcInfo].Processor.Flags = 0 then // normal core
  Result := Result SHL 1 OR bit
else // hyperthreaded core
  Result := (Result SHL 1 OR bit) SHL 1 OR bit;

Concern: According to Microsoft documentation, the Flags field can have the value LVI_CPU_FLAGS_EFFICIENT (0x01) to indicate an efficiency core. Using Flags = 0 as a proxy for "not hyperthreaded" may be:

• Undocumented behavior
• Platform-dependent
• Could break on future Windows versions

Recommendation:

• Document the assumption about Flags values
• Consider using documented flag constants if available
• Add a comment explaining why Flags = 0 indicates a non-hyperthreaded core

3. Performance: Inefficient Array Growing (DSiWin32.pas:7673)

repeat
  SetLength(info, Length(info) + 1);  // O(n²) complexity

Issue: Growing the array by 1 element at a time causes repeated memory allocations and copies, resulting in O(n²) time complexity.

Recommendation: Pre-calculate the number of elements needed or use a growth strategy:

// Option 1: Count first, allocate once
var itemCount: integer;
itemCount := 0;
// First pass: count items
// Second pass: fill array

// Option 2: Reserve capacity with growth factor
// Grow in chunks (e.g., double when full)

4. Potential Memory Leak on Exception (DSiWin32.pas:7667-7698)

If DSiGetLogicalProcessorInformationEx or the parsing loop raises an exception, the buffer allocated with GetMem may not be freed.

Recommendation: While the try-finally block is present, consider adding exception handling to ensure cleanup and prevent partial data from being returned:

try
  Result := DSiGetLogicalProcessorInformationEx(relationshipType, buffer, bufSize);
  if Result then begin
    // ... parsing logic
  end;
finally 
  FreeMem(buffer); 
end;

5. Documentation: Typo (DSiWin32.pas:5891, 5898)

"efficency" should be "efficiency" in the comments:

{:Returns affinity mask of efficency cores as a list of CPU IDs (0..9, A..V).

---

🔍 Security & Robustness

1. Bounds Checking: The code disables range checking ({$R-}) at line 7683-7686. While this may be necessary for performance, ensure that pInfo.Processor.GroupCount correctly bounds the loop to prevent buffer overruns.

2. Buffer Overflow Protection: The loop termination condition at line 7696 is correct:

until (DSiNativeUInt(pBuffer) - DSiNativeUInt(buffer)) >= bufSize;

This prevents reading beyond the allocated buffer.

---

🧪 Test Coverage

Observation: No test files were modified in this PR.

Recommendations:

1. Add unit tests for the new E-core/P-core detection functions
2. Test edge cases:
   • Systems without E-cores (should return all cores as P-cores)
   • Single-core systems
   • Error conditions (API not supported, allocation failures)
3. Test the refactored LoadNUMAInfo on various system configurations
4. Verify backward compatibility with older Windows versions

---

📝 Minor Notes

1. The .claude/settings.local.json file appears to be development configuration and probably shouldn't be committed to the repository.

2. The unittests/CompileAllUnits.dsv file seems to be an IDE-specific view state file - consider adding to .gitignore.

---

Summary

This is a solid improvement that fixes a critical type mismatch bug and adds useful functionality. The main concerns are:

• Missing error handling initialization
• Potential undefined behavior with Processor.Flags interpretation
• Performance optimization opportunity
• Test coverage needed

The bug fixes are important and the refactoring improves code quality, but please address the error handling and consider the flag interpretation issue before merging.

Recommendation: Address the critical error handling issue, then approve pending testing.

[claude]

Pull Request Review

Thank you for these improvements to the logical processor information handling! This PR addresses several important fixes and adds useful functionality for modern CPUs with efficiency cores. Overall, the changes look solid, but I have some observations and suggestions.

Code Quality & Best Practices

Positive aspects:

• Good refactoring in OtlCommon.pas - the transition from pointer arithmetic to array iteration is much cleaner and more maintainable
• Proper error handling with GetLastError checks
• Consistent code style with the rest of the codebase
• Well-structured new data types and wrapper functions

Areas for improvement:

1. Type declarations in DSiWin32.pas (lines 1765-1893): There appear to be duplicate or conflicting type definitions for _PROCESSOR_RELATIONSHIP. I see definitions at different locations with slightly different structures:

   • Lines 1787-1800: Has EfficiencyClass field
   • Lines 1925-1937: Missing EfficiencyClass field (within {$IFNDEF DSiHasGroupAffinity} block)

   This could cause compilation issues on different Delphi versions. Consider reviewing the conditional compilation blocks to ensure consistency.

2. Memory initialization in DSiGetLogicalProcessorInfoEx (line 7665): The code sets info := nil before the API call, which is good. However, if the function returns early with Result := false, the array will be empty, which is handled correctly at line 7702.

Potential Bugs & Issues

1. E-Core/P-Core detection logic (lines 5900-5952): The bit shifting logic appears to be working backwards through the array (High to Low) to build the affinity mask. A few concerns:

   • Assumption about processor ordering: The code assumes that iterating from High(info) downto 0 will produce the correct bit order. This depends on how Windows returns the processor information. It would be helpful to add a comment explaining this assumption.

   • Flags field interpretation (lines 5914, 5944): The code checks if info[iProcInfo].Processor.Flags = 0 then to detect non-hyperthreaded cores. According to Windows API documentation, the Flags field uses LTP_PC_SMT (value 0x01) to indicate hyperthreading. The logic appears inverted:

     • Flags = 0 means single-threaded core (correct in code)
     • Flags <> 0 means hyperthreaded core (correct in code)

     However, there's no constant definition for LTP_PC_SMT. Consider adding:

     const
       LTP_PC_SMT = $01; // Logical processors share functional units (SMT/Hyperthreading)

     And changing the check to: if (info[iProcInfo].Processor.Flags and LTP_PC_SMT) = 0 then

2. Array bounds in DSiGetLogicalProcessorInfoEx (line 7685): The code uses {$R-} to disable range checking when copying GroupMask arrays. While this might be necessary for performance, it's worth verifying that pBuffer.Processor.GroupMask[iGroup] won't cause access violations. The array is declared as GroupMask: array[0..0] in the structure, which is a variable-length array idiom in C-style APIs.

3. Missing initialization check (OtlCommon.pas line 4374): The code calls DSiGetLogicalProcessorInfoEx but doesn't explicitly initialize the procInfo array before the call. While the function does set it to nil internally, it would be clearer to initialize it here: procInfo := nil;

Performance Considerations

1. Memory allocation efficiency: The new DSiGetLogicalProcessorInfoEx function (lines 7655-7703) dynamically grows the array with SetLength(info, Length(info) + 1) in a loop. This could be inefficient for systems with many processors. Consider:

   • Pre-allocating based on an estimated size
   • Or counting entries first, then allocating once

   However, this is likely called infrequently (during initialization), so the current approach is probably acceptable.

2. Repeated calls in LoadNUMAInfo (OtlCommon.pas line 4374): The refactored code now properly uses the array-based API, which should perform similarly to the old pointer-based approach. The elimination of manual pointer arithmetic is worth the slight overhead.

Security Concerns

No significant security issues identified. The code properly:

• Validates buffer sizes before allocation
• Checks API return values
• Handles error conditions appropriately
• Uses safe memory management with try-finally blocks

Test Coverage

The PR doesn't include explicit unit tests for the new E-Core/P-Core detection functions. Consider adding tests that:

• Verify correct affinity mask generation on systems with/without E-cores
• Test behavior on single-core, multi-core, and hyperthreaded systems
• Validate edge cases (all E-cores, all P-cores, mixed configurations)

Since this is low-level CPU detection, testing might require different hardware configurations or mocking the Windows API responses.

Documentation

The new functions have minimal documentation comments. Consider adding more detailed documentation for:

• DSiGetSystemECoreAffinityMask (line 5900): Explain the bit ordering and what EfficiencyClass values mean
• DSiGetSystemPCoreAffinityMask (line 5930): Document the fallback behavior when no E-cores are detected
• DSiGetLogicalProcessorInfoEx (line 7655): Document the structure of the returned array

Minor Issues

1. Whitespace inconsistency: Some array indexing has inconsistent spacing (e.g., info[Length(info)-1] vs info[iInfo])

2. File included in PR (.claude/settings.local.json): This appears to be a local configuration file that probably shouldn't be committed to the repository. Consider adding it to .gitignore.

3. File included in PR (unittests/CompileAllUnits.dsv): This looks like an IDE-specific file with user-specific paths. Should this be in version control?

Summary

This is a solid PR that fixes important bugs and adds useful functionality. The main concerns are:

1. Clarify the processor ordering assumptions in the E-Core/P-Core detection
2. Add the LTP_PC_SMT constant for better code clarity
3. Review the duplicate type definitions for compatibility
4. Consider removing the local configuration files from the PR
5. Add more comprehensive documentation

The core functionality appears sound, but testing on various CPU configurations (Intel with E-cores, AMD, older Intel) would be valuable to ensure correctness.

Recommendation: Approve with minor changes requested for the documentation and potential cleanup of the committed local files.

[claude]

Pull Request Review: Fixed DSiGetLogicalProcessorInformationEx and LoadNumaInfo

Summary

This PR fixes a critical bug in DSiGetLogicalProcessorInformationEx and refactors LoadNUMAInfo to use a cleaner array-based approach. It also adds new functionality for retrieving CPU affinity masks for efficiency cores (E-cores) and performance cores (P-cores), which is valuable for modern Intel hybrid architectures.

---

Positive Aspects

Code Quality

• Cleaner abstraction: The new DSiGetLogicalProcessorInfoEx wrapper (DSiWin32.pas:7655-7702) properly encapsulates the complex buffer management and provides a much cleaner array-based interface
• Simplified caller code: The refactored LoadNUMAInfo (OtlCommon.pas:4360-4395) is significantly simpler - removed manual pointer arithmetic and error-prone buffer traversal
• Type safety improvement: Fixed the buffer type bug where DSiGetLogicalProcessorInformationEx incorrectly used PSYSTEM_LOGICAL_PROCESSOR_INFORMATION instead of PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX (DSiWin32.pas:2076,2332,2502)
• Good documentation: Function documentation follows the project's convention with {: style comments

New Functionality

• The E-core/P-core affinity functions (DSiWin32.pas:5891-5952) are well-designed and handle edge cases appropriately:
  • Graceful fallback when the API is unsupported
  • Correct handling of CPUs without E-cores (returns all cores as P-cores)
  • Proper hyperthreading detection via the Flags field

---

Issues and Concerns

1. Memory Leak Risk (Minor - already handled correctly)

DSiWin32.pas:7667-7698 - The GetMem/FreeMem pattern is correct, but worth noting:

GetMem(buffer, bufSize);
try
  // ... operations
finally FreeMem(buffer); end;

This is properly implemented. Good defensive programming.

2. Potential Type Confusion (Low severity)

DSiWin32.pas:7676-7694 - The code handles multiple relationship types but doesn't have explicit handling for unrecognized types:

case pInfo.Relationship of
  RelationProcessorCore, RelationProcessorDie, RelationProcessorModule, RelationProcessorPackage:
    // handled
  RelationNumaNode, RelationNumaNodeEx:
    // handled
  RelationCache:
    // handled
  RelationGroup:
    // handled
  // else: What happens with future relationship types?
end;

Recommendation: Consider adding an else branch that either logs a warning or sets a default state for forward compatibility.

3. Array Indexing Concern (Medium severity)

DSiWin32.pas:7673-7674:

SetLength(info, Length(info) + 1);
pInfo := @info[Length(info)-1];

This pattern of repeatedly growing an array is inefficient (O(n²) complexity for n items).

Recommendation: Consider pre-allocating or using a growth strategy. You could estimate the size by dividing bufSize by a reasonable minimum structure size, or use exponential growth (e.g., grow by 1.5x when needed).

4. Range Check Disable (Minor security concern)

DSiWin32.pas:7683-7686:

{$R-}
for iGroup := 0 to High(pInfo.Processor.GroupMask) do
  pInfo.Processor.GroupMask[iGroup] := pBuffer.Processor.GroupMask[iGroup];
{$IFDEF RestoreR}{$R+}{$ENDIF}

Concern: Range checking is disabled, which could mask buffer overrun bugs if GroupCount is incorrect or if there's a mismatch between the Windows API structure and your definitions.

Recommendation: Add an assertion or bounds check before the loop:

Assert(pInfo.Processor.GroupCount <= Length(pBuffer.Processor.GroupMask));

5. E-core/P-core Bit Manipulation Logic (Potential bug)

DSiWin32.pas:5910-5918 and DSiWin32.pas:5940-5948:

for iProcInfo := High(info) downto 0 do begin // get bits in correct order
  bit := 0;
  if info[iProcInfo].Processor.EfficiencyClass = 0 then
    bit := 1;
  if info[iProcInfo].Processor.Flags = 0 then // normal core
    Result := Result SHL 1 OR bit
  else // hyperthreaded core
    Result := (Result SHL 1 OR bit) SHL 1 OR bit;
end;

Concerns:

• The comment "get bits in correct order" suggests order matters, but the Windows API doesn't guarantee the order of returned processor information
• The Flags field check (Flags = 0 for normal, non-zero for hyperthreaded) may not be explicitly documented in the Windows API
• On systems with >64 processors, this will overflow DSiNativeUInt

Recommendation:

• Verify Windows API ordering guarantees
• Document the assumption about the Flags field
• Consider adding overflow protection or limiting to 64 cores with a warning

6. Error Handling Gap

OtlCommon.pas:4374-4377:

DSiGetLogicalProcessorInfoEx(DSiWin32._LOGICAL_PROCESSOR_RELATIONSHIP.RelationAll, procInfo);
if GetLastError = ERROR_NOT_SUPPORTED then
  CreateFakeNUMAInfo
else begin

Issue: This assumes that if GetLastError <> ERROR_NOT_SUPPORTED, then the call succeeded. But DSiGetLogicalProcessorInfoEx could fail for other reasons (e.g., ERROR_INSUFFICIENT_BUFFER shouldn't happen but other errors could).

Recommendation: Check the return value explicitly:

if not DSiGetLogicalProcessorInfoEx(...) then begin
  if GetLastError = ERROR_NOT_SUPPORTED then
    CreateFakeNUMAInfo
  else
    raise Exception.CreateFmt('LoadNUMAInfo: Failed to get processor info [%d] %s', 
      [GetLastError, SysErrorMessage(GetLastError)]);
end

---

Performance Considerations

Positive

• The refactored LoadNUMAInfo eliminates manual pointer arithmetic, which should be slightly faster and more cache-friendly
• The wrapper function handles memory management once instead of requiring each caller to manage buffers

Area for Improvement

• The repeated SetLength in the parsing loop (mentioned in task.Terminated does not work as expected #3 above) causes multiple memory reallocations
• Consider pre-calculating the number of records by doing a preliminary scan of the buffer

---

Security Assessment

Low Risk Overall:

• Proper memory management with try/finally
• No obvious buffer overflows in the new code
• The fix to use the correct buffer type (PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX) actually improves safety

Minor concerns:

• Range checking disabled (see redesign thread pool #4)
• No validation of data from Windows API before use

---

Test Coverage

Concern: This PR includes no new tests for:

• The new E-core/P-core affinity functions
• The refactored LoadNUMAInfo
• The new DSiGetLogicalProcessorInfoEx wrapper

Existing test: test_64_ProcessorGroups_NUMA.pas likely exercises LoadNUMAInfo, but should be verified to ensure it still passes.

Recommendation: Add unit tests for:

1. DSiGetSystemECoreAffinityMask / DSiGetSystemPCoreAffinityMask on various CPU types
2. Edge cases: CPUs without E-cores, single-core systems, >64 core systems
3. Verify the fix actually resolves the original issue

---

Additional Notes

1. .claude/settings.local.json: This file is included in the PR but appears to be a local configuration file. Should this be in .gitignore?

2. unittests/CompileAllUnits.dsv: This appears to be IDE-specific state. Should this be excluded from version control?

3. Version numbering: The change bumps DSiWin32 from 2.09→2.11 (skipping 2.10?) and OtlCommon to 1.55b. Verify this follows the project's versioning conventions.

---

Recommendations Summary

Must Fix:

• Add explicit error handling in LoadNUMAInfo (issue task-wrapping TComponent #6)
• Verify and document the processor ordering assumption in E-core/P-core functions (issue reduce number of messages sent from IOmniCommunicationEndpoint and TOmniEventMonitor #5)

Should Fix:

• Optimize array growth in DSiGetLogicalProcessorInfoEx (issue task.Terminated does not work as expected #3)
• Add bounds checking or assertions before the range-check-disabled loop (issue redesign thread pool #4)

Consider:

• Add test coverage for new functionality
• Review whether IDE-specific files should be committed
• Add default case to relationship type switch

---

Conclusion

This is a solid improvement that fixes a real bug and adds useful functionality for modern CPUs. The refactoring makes the code cleaner and more maintainable. With the recommended fixes above, particularly the error handling and array growth optimization, this would be excellent code.

The new E-core/P-core functionality is particularly valuable for applications that want to optimize thread placement on hybrid Intel architectures.

Status: Approve with minor recommendations for follow-up improvements.

[bito-code-review]

Bito Review Skipped - No Changes Detected

Bito didn't review this pull request because we did not detect any changes in the pull request to review.