> В перекидывании потока: за ним ведь приходится тянуть все кеши.Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его квант истёк, его вытеснил поток B. Вдруг ядро 2 начало простаивать, а A стоит в очереди на ядро 0, которое находится в той же ноде, что и ядро 2. Ядро 2 должно простаивать? Или может всё таки лучше забрать поток A себе? Планировщик скорее всего сделает последнее (за вычетом ограничений affinity и подобного). Кэши просто так никто перетягивать не будет. Поток B вероятнее всего уже весь кэш L1 заполнил своими данными. А L2 может вообще быть общим для ядер 0 и 2. Что перетягивать? Как перетягивать? Да, будут cache miss'ы. Но это лишь замедление работы, а не полное простаивание ядра (пока есть работа в очереди).
> Какая разница планировщику какие ядра будут простаивать без работы?
Они не будут (простаивать без работы). См. выше.
> Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное?
Не зачем. Но поток не может вечно крутится на ядре. Он может крутится лишь определённый кусок времени (квант), затем он должен уступить другим потокам. В этот момент и может произойти ситуация, описанная выше, где поток A - это как раз "поток кушающий 100% времени процессорного ядра".
> Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе?
Нет, конечно. Потоки могут выполняться не только на последнем использованном для выполнения ядре, они действительно могут "перекидываться". См. пример выше.
> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на твоё первое сообщение 4.81.
> Я отмечу, что ты не предлагаешь никакой альтернативы им.
В моём же сообщении 3.61 я сразу написал:
> Советую почитать Windows Internals, например 7-ое издание.
Ибо там, даже если очень лень вникать, просто из содержания можно извлечь ложность утверждений из статьи.
> Thread selection on multiprocessor systems
> Heterogeneous scheduling (big.LITTLE)
Про то, что планировщик Windows знает, про разницу между физическими и логическими ядрами, рассказывает раздел "Package sets and SMT sets", но увы, тут уже придётся вчитаться хотя бы в первый его параграф.
> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
Я не знаток конечно, я лишь консультирую по NT Internals. Зачем я должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? Смысл пересказывать содержимое книги?
