Приложения, процессоры, память и кэши

Оптимизированные многопоточные приложения должны знать число доступных процессоров (для параллелизма), и размер и совместное использование кэшей процессора (для памяти, совместно использующей).

OS X не экспортирует интерфейсы, идентифицирующие процессоры или управляющие размещением потока — явный поток к привязке процессора не поддерживается. Вместо этого ядро управляет всем размещением потока. Приложения ожидают, что планировщик, при большинстве обстоятельств, выполнит свои потоки с помощью хорошего размещения процессора относительно сродства кэша.

Однако само приложение знает подробные характеристики кэширования своих потоков и своих данных — в частности организация потоков как непересекающиеся наборы, охарактеризованные их связью с (сродство к) отличные совместно используемые данные.

В то время как потоки в таком наборе показывают сродство друг с другом через совместно используемые данные, они совместно используют disaffinity или отрицательное сродство относительно других наборов. Другими словами, набор выражает сродство кэшем L2, и планировщик должен стремиться выполнить потоки в наборе на процессорах, совместно использующих это кэш L2.

Для поддержки этого два новых APIs представлен в Leopard:

• Механизм для приложения к явно выраженному сродству потока подсказывает планировщику как расширение политик потока Маха.

• Более универсальный и полный набор sysctl(3) средства управления для получения информации делящегося кэша процессора.

Сродство потока API

Набор сродства является набором потоков, совместно использующих ресурсы памяти и желание совместно использовать кэш L2. Отличные наборы сродства представляют отдельное сродство — т.е. потоки, принадлежащие различному набору, должны использовать отдельный кэш L2 и следовательно быть выполнены на различные логические процессоры.

Набор сродства идентифицируется «тегом». Потоки присваиваются определенному сродству, установленному путем присвоения его тег, идентифицирующий тот набор. Поток может принадлежать самое большее одному набору сродства; т.е. это имеет один тег сродства. Значение по умолчанию, нуль, тег не представляет сродства.

Каждая задача имеет отличную вселенную наборов сродства и таким образом частного пространства имен тегов; значение тега в одной задаче не идентифицирует тот же набор сродства в другой задаче.

Вызовы политики потока Маха определяются в заголовке /usr/include/mach/thread_policy.h и в /System/Library/Frameworks/System.framework/PrivateHeaders/mach/thread_policy.h следующим образом:

kern_return_t thread_policy_set(
                        thread_t        thread,
                        thread_policy_flavor_t flavor,
                        thread_policy_t     policy_info,
                        mach_msg_type_number_t count);

kern_return_t  thread_policy_get(
                        thread_t        thread,
                        thread_policy_flavor_t flavor,
                        thread_policy_t     policy_info,
                        mach_msg_type_number_t *count);
                        boolean_t        *get_default);

Эти вызовы были расширены путем добавления новой разновидности политики потока:

#define THREAD_AFFINITY_POLICY         4

struct thread_affinity_policy {
        integer_t    affinity_tag;
};
typedef struct thread_affinity_policy   thread_affinity_policy_data_t;
typedef struct thread_affinity_policy   *thread_affinity_policy_t;

#define THREAD_AFFINITY_POLICY_COUNT  ((mach_msg_type_number_t) \
                (sizeof (thread_affinity_policy_data_t) / sizeof (integer_t)))

#define THREAD_AFFINITY_TAG_NULL        0

Установкой a (ненуль) тег сродства для потока поток помещается в набор сродства, идентифицированный «тегом». По умолчанию все потоки имеют THREAD_AFFINITY_NULL сродство. Ненулевой тег произволен и может передать специализированную информацию.

thread_policy_set(THREAD_AFFINITY_POLICY) вызов может быть выполнен после создания потока, но прежде, чем запустить его выполнение для влияния на его исходное размещение.

Например, приложение, желающее работать на 2 потоках, отделяется, кэши L2 установили бы потоки с различными тегами сродства. На двухъядерной машине будет эффективно проигнорировано это сродство. Однако на Макпро с 4 ядрами, планировщик попытается выполнить потоки на отдельных пакетах. Точно так же на Макпро с 8 ядрами, планировщик попытается работать на этих отдельных потоках, умирает (который может или может не быть в том же физическом пакете CPU).

Приложение с производителем и потребительским потоком, который должен совместно использовать кэш L2, выполнило бы следующие шаги:

• Создайте оба потока.

• Установите тот же тег сродства для каждого потока.

• Запустите оба потока.

Приложение, хотящее поместить поток в каждый доступный процессор, сделало бы следующее:

• Получите число процессоров на системном использовании sysctl(3) (см. ниже).

• Создайте то число потоков.

• Установите каждый поток с отличным тегом сродства.

• Запустите все потоки.

Потоки с политикой сродства по умолчанию будут запланированы более свободно на любом процессоре. Эти потоки будут предпочтительно перемещены для работы неактивного процессора. Потоки с тегами сродства будут иметь тенденцию оставаться на месте.

Обычно пространство имен тега сродства является частным к одной задаче (процесс). Однако дочерний процесс разветвился после того, как его родитель сделал a THREAD_AFFINITY_POLICY вызов совместно использует пространство имен сродства родительского процесса. Это позволяет семейству разветвленных процессов совместно использовать пространство имен сродства несмотря на включение отдельных задач. Кроме того, разветвленный дочерний элемент наследовал тег сродства его родителя. Следовательно, родитель может отобрать много дочерних процессов в произвольной организации совместно используемых наборов сродства.Примечание: наследование пространства имен сродства уничтожается exec(3) системный вызов, как бы то ни было.

Кроме того, заголовок /usr/include/mach/task_info.h включает следующий новый информационный запрос:

struct task_affinity_tag_info {
        integer_t        count;
        integer_t        min;
        integer_t        max;
        integer_t        task_count;
};
typedef struct task_affinity_tag_info   task_affinity_tag_info_data_t;
typedef struct task_affinity_tag_info   *task_affinity_tag_info_t;
#define TASK_AFFINITY_TAG_INFO          16
#define TASK_AFFINITY_TAG_INFO_COUNT    \
                (sizeof(task_affinity_tag_info_data_t) / sizeof(natural_t))

Это позволяет Вам получить число (count) и диапазон [min .. max] из сродства в настоящее время тегирует определяемый для задачи.

sysctl для Размеров кэша и Совместного использования Уровней

Для Leopard, hw.cacheconfig sysctl сообщает о числе логических процессоров, совместно использующих кэши на различных уровнях в системе. Это:

• hw.cacheconfig[0] сообщает RAM, совместно использующий (общее количество логических процессоров).

• hw.cacheconfig[1] сообщает L1, совместно использующий (число логических процессоров, совместно использующих кэш уровня 1).

• hw.cacheconfig[2] сообщает совместное использование L2.

• ...

Там уже отсортированы средства управления sysctl, сообщающие о размере различных кэшей. Они продолжают существовать для совместимости, но эта информация теперь консолидируется в hw.cachesize где:

• hw.cachesize[0] сообщает размер памяти.

• hw.cachesize[1] сообщает размер кэша данных L1.

• hw.cachesize[2] сообщает размер кэша L2.

• ...

Оба hw.cacheconfig и hw.cachesize массивы 64-разрядных значений.

Следовательно, hw.cacheconfig и hw.cachesize предоставьте информацию, необходимую для приложения для конфигурирования:

• его уровень поточной обработки для максимального параллелизма

• пространство буфера для резиденции кэша

• сродство подсказывает для размещения потока и совместного использования кэша.

sysctl для количества Корпуса процессора

Число настоящего корпусов процессора на машине публикуется через hw.packages. Для того, чтобы в настоящее время поставить обрабатывает машинным способом, это 1 или 2.

sysctl для Семейства процессоров

sysctl hw.cpufamily публикует значение, идентифицирующее микроархитектурное семейство процессора. Это значение произвольно выбрано, чтобы быть уникальным для этой семьи. Никакое числовое отношение не может быть выведено ни между какими двумя значениями. Настоящее функций процессора в любой семье должно быть определено путем запросов другого определенного hw.optional переменные.

Значения, возвращенные для семейств процессоров, поддерживаемых Leopard:

Для получения дополнительной информации

Для получения дополнительной информации об использовании sysctl средства управления, см. Граничную главу Пересечений Руководства по программированию Ядра и страниц руководства для sysctl(3), sysctlbyname(3), и sysctl(8) команда.