`OMP_PLACES` without `OMP_PROC_BIND` caps every thread pool at the bound core

オープン 初心者向け
  • 何か問題がありますか？
#172 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
半日
初心者へのやさしさ
66/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
performance

調査の方向性

src/solprop/_process.py の allowed_cpus から始めてください。ここでは OMP_PROC_BIND のチェックによって、アフィニティマスクをバインディングとして扱うかどうかが決まります。同じテストで、backends/numba_cpu/openmp.py と同様に OMP_PLACES だけの場合もカバーしてください。tests/test_process.py に、既存のアフィニティテストの近くに OMP_PLACES のみのケースを追加してください。再現スクリプトが両方の環境で 72 を出力し、既存のテストがすべて通れば完了です。issue が求めている Linux での libgomp と libomp の確認が前提条件になります。

索引モデルが issue の本文から書いたものです。

説明

area: backends bug priority: low
What happens

GNU OpenMP binds the main thread to its first place, and OMP_PLACES alone is enough to make it do so. allowed_cpus must not mistake that binding for the scheduler's grant, or the thread budget (ADR-052) sizes every pool to one core.

It now handles this when OMP_PROC_BIND is set, for one CPU and for the hardware threads of one core, with tests. That is more than the roadmap's text says, and its description is out of date for that case. With OMP_PLACES=cores and no OMP_PROC_BIND, though, the test binding not in {"", "false"} fails, and the two-CPU mask is believed as a deliberate restriction.

Reproduction

macOS has no affinity call, so this patches a 72-CPU grant and a core of two hardware threads in, on an Apple M5 Max (18 cores), 2026-11-01. No Linux run was made, so the effect on a real pool is by reading.

import os
from unittest import mock

import solprop._process as process

grant = tuple(range(72))  # what the scheduler gave
bound = (0, 36)  # one core's two hardware threads: an OpenMP place of one core
for env in ({"OMP_PROC_BIND": "spread", "OMP_PLACES": "cores"}, {"OMP_PLACES": "cores"}):
    with mock.patch.dict(os.environ, env), \
         mock.patch.object(process, "_AT_IMPORT", grant), \
         mock.patch.object(process, "_query", lambda: bound), \
         mock.patch.object(process, "physical_cores", lambda cpus, root=None: 1 if len(cpus) == 2 else 36):
        print(env, "->", len(process.allowed_cpus()), "CPUs")

{'OMP_PROC_BIND': 'spread', 'OMP_PLACES': 'cores'} -> 72 CPUs
{'OMP_PLACES': 'cores'} -> 2 CPUs
Context

The SEP 27 campaign found the original cap in its execution metadata and worked round it with explicit places. numba_cpu's warning about a binding names both variables. #130 is about a native run ignoring the budget on a Python thread, a separate defect.

To do
  • Run the case on Linux with libgomp and with libomp: does OMP_PLACES alone bind the main thread on each? The fix is only right where it does.
  • Use the same test for both variables, as openmp.py does.
  • Add a case to tests/test_process.py for OMP_PLACES alone.

Must not change: a deliberate narrowing to several cores, or a mask outside the import-time set, is still believed, and the existing affinity tests still pass.

Done when

The script above prints 72 for both rows, a test holds it, and a Linux run with OMP_PLACES=cores alone shows the pools at the grant.

Checked against commit 8a9f764. Takes over the roadmap's entry "OpenMP core places and the Numba allocation cap."

主要言語
Python
スター
3
フォーク
3
平均マージ
8時間 28分
マージ済み PR（30日）
176

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

LupoLab/solprop のほかの issue

LupoLab/solprop の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。