The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлен новый вариант планировщика задач BFS

16.12.2012 22:31

В списке рассылки разработчиков ядра Linux представлен новый планировщик задач, основанный на коде планировщика BFS (Brain Fuck Scheduler), но отличающийся возможностью использования нескольких очередей выполнения (runqueue). Патчи с реализацией нового планировщика подготовлены для ядра 3.6.2 (в оригинальном BFS несколько дней назад появилась поддержка ядра 3.7).

Планировщик BFS ориентирован на обеспечение оптимальной отзывчивости, интерактивности и пропускной способности при решении типичных пользовательских задач на обычных компьютерах. Основная реализация BFS, поддерживаемая Коном Коливасом (Con Kolivas), манипулирует процессами в рамках одной глобальной очереди задач для всех CPU, что позволяет свести к минимуму паразитную нагрузку от работы планировщика, но приводит к проблемам с масштабируемостью на многоядерных системах (BFS эффективен на системах, имеющих менее 16 ядер). Маттиас Кёлер (Matthias Kohler), автор нового варианта BFS, переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах.

Суть внесённых изменений сводится к добавлению нескольких очередей выполнения, каждая из которых привязывается к одному или нескольким ядрам CPU и отвечает за планирование выполнения процессов только для указанных ядер CPU. Таким образом, удаётся обойти проблемы с масштабируемостью BFS на системах с большим числом процессорных ядер. Ценой наличия нескольких очередей является необходимость поддержания дополнительных механизмов для балансировки нагрузки между очередями, что снижает эффективность.

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

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

  1. Главная ссылка к новости (https://lkml.org/lkml/2012/12/...)
  2. OpenNews: Обновление планировщика задач BFS с поддержкой ядра Linux 3.3
  3. OpenNews: Автор CFS провел исследование производительности планировщика задач BFS
  4. OpenNews: Кон Коливас представил BFS, новый планировщик задач для Linux ядра
  5. OpenNews: Для ядра Linux представлен планировщик задач RIFS-ES
  6. OpenNews: Для ядра Linux представлена шестая версия планировщика задач SCHED_DEADLINE
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/35618-bfs
Ключевые слова: bfs, scheduler, cpu, linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:22, 16/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на процессоре(ах) ускорится или нет ?
     
     
  • 2.2, AEffect (?), 23:40, 16/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В теории - да
     
  • 2.3, all_glory_to_the_hypnotoad (ok), 23:41, 16/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    нет
     
     
  • 3.18, Аноним (-), 07:47, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Расскажи это GPU, битком набитому SIMD-образными числокрушилками.
     
     
  • 4.37, pavlinux (ok), 16:01, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/

    1. Тема по CPU шыдулер
    2. Тред про рендеринг.
    3. SIMD и GPU, гы...  

    [сообщение отредактировано модератором]

     
  • 2.5, Аноним (-), 23:45, 16/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на
    > процессоре(ах) ускорится или нет ?

    нет, конечно.

     
  • 2.8, Lain_13 (ok), 00:20, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Рендер требует очень много floating-point операций. Видеокарта это умеет делать значительно лучше процессора — она специально на это заточена. Так что нет, привлечение процессора только замедлит работу. Разве что как вспомогательное звено если недогружен.
     
     
  • 3.13, Аноним (-), 03:04, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Аха только вот почему то все программы рендеринга делают свое дело на CPU
     
     
  • 4.15, Elenium (ok), 07:01, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Blender c Cycles render использует GPU например, причем на глаз раз в 5 быстрее рендерить на gpu (core 2 duo 3гг, gtx 570 ti)
     
  • 4.19, Аноним (-), 07:48, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Аха только вот почему то все программы рендеринга делают свое дело на CPU

    Это вы просто с ручника еще не снялись. Вот и ...

     
  • 2.9, Аноним (-), 00:45, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не должно, это просто увеличивает скорость переключения между потоками, скорость самих потоков не изменяется
     
     
  • 3.10, all_glory_to_the_hypnotoad (ok), 01:24, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    неправда, скорость самих потоков может замедлится. Любой планировщик с хорошей отзивчивостью для десктопного испольщования гробит производительность отдельно взятого потока/процесса.
     
     
  • 4.25, pro100master (ok), 10:44, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а может и ускориться, если попадут в кеш. Зависит от конкретной реализации. Так что тут только кофейная гуща и шарик )
     
     
  • 5.32, Crazy Alex (ok), 14:44, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
     
     
  • 6.38, pavlinux (ok), 16:12, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует

    По какой такой идее?

     
     
  • 7.56, Crazy Alex (ok), 11:46, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
    >  По какой такой идее?

    Ну как же -  чем дольше активен один поток - тем дольше нужен уму его кэш. Запустили другой - у него инструкции/данные другие - грузи заново...

     
     
  • 8.61, pavlinux (ok), 06:24, 19/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    По частоте попадания в кэш, можно судить об не оптимальности алгоритма Если пор... текст свёрнут, показать
     
     
  • 9.62, all_glory_to_the_hypnotoad (ok), 23:18, 19/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вообще нерелевантный показатель для что-то там не так ... текст свёрнут, показать
     
     
  • 10.63, pavlinux (ok), 16:50, 21/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    if a 10 x a else if a 200 x a 2 else if a 50 ... текст свёрнут, показать
     
     
  • 11.64, Led (ok), 02:57, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Нет такого файла в ядре - наверное ты сам его и дописал ... текст свёрнут, показать
     
     
  • 12.65, pavlinux (ok), 18:57, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А то, сижу пешу 2 6 - 2 6 23 arch i386 pci mmconfig c arch i386 pci mmconfig-s... текст свёрнут, показать
     
     
  • 13.66, Led (ok), 22:10, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Эти файлы есть Но представленного тобой кода в них нет Значит этот быдлокод та... текст свёрнут, показать
     
     
  • 14.67, pavlinux (ok), 22:24, 22/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    нужно - найдешь, ориентир MMCONFIG... текст свёрнут, показать
     
     
  • 15.68, Led (ok), 00:00, 23/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я по всему дереву исходников грепал - нет в ядре такого кода... текст свёрнут, показать
     
     
  • 16.69, pavlinux (ok), 03:13, 23/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно нет А кто говорил, что этот код из ядра ... текст свёрнут, показать
     
     
  • 17.70, fidaj (ok), 13:27, 23/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    удивительные иногда диалоги на опеннете Сообщение от pavlinux ok on 21-Дек... текст свёрнут, показать
     
  • 17.71, Led (ok), 21:40, 23/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ... текст свёрнут, показать
     
  • 6.39, pro100master (ok), 16:24, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ключевое слово *может*. Т.е. в жизни разное бывает. Когда вторые корки появились с большим кешем, наблюдал 10-кратный рост на одной задачке CGI мультитредовой (частота и пр. кроме кеша были одинаковые).
     
     
  • 7.46, all_glory_to_the_hypnotoad (ok), 21:33, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а задачка тоже в обоих случаях была мультитредовой?
     
  • 5.45, all_glory_to_the_hypnotoad (ok), 21:18, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну это совсем навряд ли. Чем мельче гранулярность (т.е. low latency планеровщик), тем выше конкруренция за единицу кэша в единицу времени (~ лезет больше потоков со своими локально уникальными данными). Фактически эффективной работе кэша это тоже вредит.
     

  • 1.4, devl547 (ok), 23:43, 16/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    То есть они прибили весь смысл single run-queue, на котором BFS строилась. Ну что, молодцы.
     
     
  • 2.7, аноним_пришел (?), 00:02, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Читай внимательнее. Для желающих оставить одну очередь на все CPU эта возможность осталась.
     

  • 1.11, Аноним (-), 02:53, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно было бы увидеть сравнительные тесты
     
  • 1.12, Пиу (?), 02:55, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче - свой инструмент?
     
     
  • 2.14, Аноним (-), 03:56, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче
    > - свой инструмент?

    Может это как бы намек что не для серверов этот планировщик.

     
  • 2.16, pers (??), 07:14, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +9 +/
    подождите пару лет - и в телефоне не будет хватать 16 ядер :)
     
     
  • 3.26, fidaj (ok), 10:53, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > подождите пару лет - и в телефоне не будет хватать 16 ядер
    > :)

    через пару лет "это" уже не будет называться телефоном...

     
  • 2.17, slezhuk (?), 07:29, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    16 ядер должно хватить каждому!
     
     
  • 3.21, atropos (?), 08:33, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    хэх, копирайтер, не вспомнят тебя через 10 лет.
     
  • 3.29, GentooBoy (ok), 12:53, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Письмо в будущее себе пошли, потом поржеш через 10 лет.
     
     
  • 4.34, Аноним (-), 15:47, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > поржеш

    Вас граммар-наци расстреляют явно быстрее чем через 10 лет, если продолжите в таком же духе.


     
  • 3.72, Anonim2023 (?), 12:44, 11/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    2023 на дворе, 32 потока в домашних процессорах
     
  • 2.20, Аноним (-), 07:50, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > на каком же десктопе/лаптопе более 16 ядер?

    Наверное потому что десктоп у которого ядер меньше чем у МОБИЛЬНИКА будет смотреться издевательски. И кстати 8-ядерники для мобил и планшетов уже анонсированы.

     

  • 1.22, Аноним (-), 09:07, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ждём выхода Brain Fuck Linux - дистрибутива где этот планировщик используется по умолчанию
     
     
  • 2.23, Аноным (ok), 10:19, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    PCLinuxOS
     
  • 2.24, Анончик (?), 10:20, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Установите Ubuntu
     
     
  • 3.30, Аноним (-), 14:42, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Установите Ubuntu

    Если дистрибутив трахает юзеру мозг - это еще не значит, что там используется BFS.

     

  • 1.27, linux must _RIP_ (?), 12:04, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.
     
     
  • 2.35, Аноним (-), 15:49, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Что можно сказать.. Все равно не примут этот шедулер в mainstream -
    > RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.

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

     
     
  • 3.49, linux must _RIP_ (?), 00:01, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Что можно сказать.. Все равно не примут этот шедулер в mainstream -
    >> RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.
    > Ох, запилите уже свою операционку с шахматами и поэтессами и покажите этому
    > гадкому линуксу как надо работать.

    Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH получает - где он один из главных акционеров.. Так что работать против своего кошелька не будет..

     
     
  • 4.54, Аноним (-), 09:41, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH
    > получает - где он один из главных акционеров..

    Завидовать нехорошо.
    Продолжайте чистить сортиры, авось к пенсии тоже на пару акций накопите :)

     
  • 2.53, Аноним (-), 09:40, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.

    Напоминает ситуацию с секс-меньшинствами и их дискриминацией. "Если какой-то гoвнокод не принимают в ядро - значит, это дискриминация по признаку авторства. Надо срочно принять и извиниться!"
    К счастю, ядром, в отличие от некоторых государств, управляют отнюдь не долбанутые толерасты.

     

  • 1.28, Аноним (-), 12:32, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Brain Fuck Scheduler"
    Вот почему его в основную ветку не взяли :) Несмотря на то, что отец ядра любит комбинацию из среднего пальца крутить.

     
     
  • 2.55, Аноним (-), 09:43, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "Brain Fuck Scheduler"
    > Вот почему его в основную ветку не взяли :) Несмотря на то,
    > что отец ядра любит комбинацию из среднего пальца крутить.

    Не хочу разбивать ваши воздушные замки, но не взяли просто потому, что гoвнокод. А не из-за названия.

     

  • 1.31, akamit (ok), 14:44, 17/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Этого доктора уже вроде посылали, он обиделся и вот опять лезет.
     
     
  • 2.33, fidaj (ok), 15:35, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Этого доктора уже вроде посылали, он обиделся и вот опять лезет.

    перечитай - это теперь уже другой лезет "дохтур"
    не все "дохтуры" одинаково полезны...

     
  • 2.36, Аноним (-), 15:50, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Этого доктора уже вроде посылали, он обиделся и вот опять лезет.

    А доктор кстати довольно приличный програмер. Он например написал свой майнер биткоинов. Кстати, один из лучших получился.

     
     
  • 3.40, Аноним (-), 17:43, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Что, кстати, намекает на уровень профессиональный уровень "профессиональных" программистов.
     
  • 2.42, Аноним (-), 20:12, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Никто его никуда не посылал.
    BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит, а "персональные" рынки с низкой маржой ей не интересны. В то же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных на персональные устройства, почему-то не заинтересовались.
     
     
  • 3.43, fidaj (ok), 20:46, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Никто его никуда не посылал.
    > BTF, в общем, хорошая штука, но актуальна только для ПК и прочих
    > персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет
    > больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит,
    > а "персональные" рынки с низкой маржой ей не интересны. В то
    > же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных
    > на персональные устройства, почему-то не заинтересовались.

    Это понятно - что абсолютно универсальных вещей в природе не бывает...
    Терзает вопрос - ну почему каждый раз изобретают велосипеды?
    Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfmk/kern/ или в Haiku http://cgit.haiku-os.org/haiku/tree/src/system/kernel/scheduler , полно и других (я говорю о тех у которых доступны исходники)...
    Зачем такие потуги?
    Или монолитность и модульность ядер уже настолько закостенела и взаимно проросла в разные подсистемы ядра что теперь простым способом нельзя отделить одно от другого?
    Вон в Haiku, опять-таки например, планировщик меняется почти как модуль, можно вообще скрестить два планировщика и настроить условия передачи обработки запросов на тот планировщик что нужно в данный момент и система будет вести себя адекватно при разных условиях использования и при этом оставаться интерактивной, и прекрасно масштабироваться...

    Что на этот счет?

     
     
  • 4.48, linux must _RIP_ (?), 23:55, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/

    > Это понятно - что абсолютно универсальных вещей в природе не бывает...
    > Терзает вопрос - ну почему каждый раз изобретают велосипеды?
    > Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты
    > (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfmk/kern/

    Ну это же фирма зла - как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца..

     
     
  • 5.51, BratSinot (?), 01:14, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца..

    Apple Public Source License FSF одобрена и является копилефтом.

     
  • 4.52, Аноним (-), 06:20, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Зачем такие потуги?

    На месте чтобы не стоять, всё правильно делают...

     
     
  • 5.58, fidaj (ok), 14:06, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Зачем такие потуги?
    > На месте чтобы не стоять, всё правильно делают...

    Двигаться - это не всегда развиваться...

     
  • 4.57, Аноним (-), 13:59, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной" нагрузке проблемы того же рода, что и у BFS.

    Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно сказывается на отзывчивости. XNU это большая удача.

     
     
  • 5.59, fidaj (ok), 14:08, 18/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной"
    > нагрузке проблемы того же рода, что и у BFS.

    хм - поподробнее пожалуйста...

    > Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно
    > сказывается на отзывчивости. XNU это большая удача.

    ну на сколько я знаю - там все реализовано через планирование нитями, впрочем, как и у планировщика Haiku...

     
  • 3.47, linux must _RIP_ (?), 23:53, 17/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Никто его никуда не посылал.

    Да ну? а фраза линукса - что есть только один шедулер и другой нам не нужен?

    > BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств.

    Ну да. коих процентов 80 у использующих. Ну да.. зачем этот рынок линуксу? лучше иметь свой 1% красноглазых и кичится этим..

     

  • 1.50, BratSinot (?), 01:07, 18/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах.

    Вот оно Линус-style. Я может чего не понимаю, но ОТКУДА на десктопах больше 16-ти ядер возьмется!? Ставлю 5$ что этот патч в офф ядро возьмут.

     
  • 1.60, SergMarkov (ok), 22:51, 18/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    значит придется ставить от коливаса До чего не дотронутся шаловливые ручонки улучшателей становится всегда хуже, а поддержка over стопицот процев как то совершенно не упала
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру