Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен новый вариант планировщика задач BFS"	+/–
Сообщение от opennews (??), 16-Дек-12, 23:22
В списке рассылки разработчиков ядра Linux представлен (https://lkml.org/lkml/2012/12/15/96) новый планировщик задач, основанный на коде планировщика  BFS (http://ck.kolivas.org/patches/bfs/) (Brain Fuck Scheduler), но отличающийся возможностью использования нескольких очередей выполнения (runqueue). Патчи с реализацией нового планировщика подготовлены для ядра 3.6.2. Планировщик BFS ориентирован на обеспечение оптимальной отзывчивости, интерактивности и пропускной способности при решении типичных пользовательских задач на обычных компьютерах. Основная реализация BFS, поддерживаемая Коном Коливасом (Con Kolivas), манипулирует процессами в рамках одной глобальной очереди задач для всех CPU, что позволяет свести к минимуму паразитную нагрузку от работы планировщика, но приводит к проблемам с масштабируемостью на многоядерных системах (BFS эффективен на системах, имеющих менее 16 ядер). Маттиас Кёлер (Matthias Kohler), автор нового варианта BFS, переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах. Суть внесённых изменений сводится к добавлению нескольких очередей выполнения, каждая из которых привязывается к одному или нескольким ядрам CPU и отвечает за планирование выполнения процессов только для указанных ядер CPU. Таким образом, удаётся обойти проблемы с масштабируемостью BFS на системах с большим числом процессорных ядер. Ценой наличия нескольких очередей является необходимость поддержания дополнительных механизмов для балансировки нагрузки между очередями, что снижает эффективность. В качестве выхода предоставлена возможность гибкой настройки числа очередей, что позволяет выбрать оптимальное число очередей для имеющегося числа процессорных ядер или особенностей рабочей нагрузки на систему. Например, возможно использование одной глобальной очереди как в классическом BFS (для максимальной отзывчивости), использование отдельной очереди для каждого ядра CPU (для максимальной масштабируемости) или привязка одной очереди к паре ядер CPU. По заявлению автора проекта разработка пока находится на стадии начального прототипа и ещё требует проведения доработки и оптимизации алгоритма балансировки нагрузки. В будущем в проект планируется добавить некоторые возможности из используемого по умолчанию в ядре Linux планировщика CFS, в основном связанные с управлением пропускной способностью и обеспечением минимальных задержек. При этом, разработка сохранит минималистичный характер и как BFS будет содержать гораздо меньше строк кода, чем в CFS. URL: https://lkml.org/lkml/2012/12/15/96 Новость: http://www.opennet.me/opennews/art.shtml?num=35618
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (-), 16-Дек-12, 23:22	+/–
Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на процессоре(ах) ускорится или нет ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #5, #8, #9

2. Сообщение от AEffect (?), 16-Дек-12, 23:40	+/–
В теории - да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от all_glory_to_the_hypnotoad (ok), 16-Дек-12, 23:41	+2 +/–
нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #18

4. Сообщение от devl547 (ok), 16-Дек-12, 23:43	–3 +/–
То есть они прибили весь смысл single run-queue, на котором BFS строилась. Ну что, молодцы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

5. Сообщение от Аноним (-), 16-Дек-12, 23:45	+2 +/–
> Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на > процессоре(ах) ускорится или нет ? нет, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от аноним_пришел (?), 17-Дек-12, 00:02	+2 +/–
Читай внимательнее. Для желающих оставить одну очередь на все CPU эта возможность осталась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

8. Сообщение от Lain_13 (ok), 17-Дек-12, 00:20	+/–
Рендер требует очень много floating-point операций. Видеокарта это умеет делать значительно лучше процессора — она специально на это заточена. Так что нет, привлечение процессора только замедлит работу. Разве что как вспомогательное звено если недогружен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

9. Сообщение от Аноним (-), 17-Дек-12, 00:45	+/–
Не должно, это просто увеличивает скорость переключения между потоками, скорость самих потоков не изменяется
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10

10. Сообщение от all_glory_to_the_hypnotoad (ok), 17-Дек-12, 01:24	+2 +/–
неправда, скорость самих потоков может замедлится. Любой планировщик с хорошей отзивчивостью для десктопного испольщования гробит производительность отдельно взятого потока/процесса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #25

11. Сообщение от Аноним (-), 17-Дек-12, 02:53	+/–
Интересно было бы увидеть сравнительные тесты
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Пиу (?), 17-Дек-12, 02:55	+1 +/–
на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче - свой инструмент?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #16, #17, #20

13. Сообщение от Аноним (-), 17-Дек-12, 03:04	+/–
Аха только вот почему то все программы рендеринга делают свое дело на CPU
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15, #19

14. Сообщение от Аноним (-), 17-Дек-12, 03:56	+/–
> на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче > - свой инструмент? Может это как бы намек что не для серверов этот планировщик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

15. Сообщение от Elenium (ok), 17-Дек-12, 07:01	+/–
Blender c Cycles render использует GPU например, причем на глаз раз в 5 быстрее рендерить на gpu (core 2 duo 3гг, gtx 570 ti)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

16. Сообщение от pers (??), 17-Дек-12, 07:14	+9 +/–
подождите пару лет - и в телефоне не будет хватать 16 ядер :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #26

17. Сообщение от slezhuk (?), 17-Дек-12, 07:29	+2 +/–
16 ядер должно хватить каждому!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #21, #29, #72

18. Сообщение от Аноним (-), 17-Дек-12, 07:47	–1 +/–
Расскажи это GPU, битком набитому SIMD-образными числокрушилками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #37

19. Сообщение от Аноним (-), 17-Дек-12, 07:48	+2 +/–
> Аха только вот почему то все программы рендеринга делают свое дело на CPU Это вы просто с ручника еще не снялись. Вот и ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

20. Сообщение от Аноним (-), 17-Дек-12, 07:50	+/–
> на каком же десктопе/лаптопе более 16 ядер? Наверное потому что десктоп у которого ядер меньше чем у МОБИЛЬНИКА будет смотреться издевательски. И кстати 8-ядерники для мобил и планшетов уже анонсированы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

21. Сообщение от atropos (?), 17-Дек-12, 08:33	+/–
хэх, копирайтер, не вспомнят тебя через 10 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

22. Сообщение от Аноним (-), 17-Дек-12, 09:07	+/–
ждём выхода Brain Fuck Linux - дистрибутива где этот планировщик используется по умолчанию
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #24

23. Сообщение от Аноным (ok), 17-Дек-12, 10:19	+/–
PCLinuxOS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Анончик (?), 17-Дек-12, 10:20	–2 +/–
Установите Ubuntu
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30

25. Сообщение от pro100master (ok), 17-Дек-12, 10:44	+/–
а может и ускориться, если попадут в кеш. Зависит от конкретной реализации. Так что тут только кофейная гуща и шарик )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32, #45

26. Сообщение от fidaj (ok), 17-Дек-12, 10:53	–2 +/–
> подождите пару лет - и в телефоне не будет хватать 16 ядер > :) через пару лет "это" уже не будет называться телефоном...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

27. Сообщение от linux must _RIP_ (?), 17-Дек-12, 12:04	–2 +/–
Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35, #53

28. Сообщение от Аноним (-), 17-Дек-12, 12:32	+/–
"Brain Fuck Scheduler" Вот почему его в основную ветку не взяли :) Несмотря на то, что отец ядра любит комбинацию из среднего пальца крутить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55

29. Сообщение от GentooBoy (ok), 17-Дек-12, 12:53	–3 +/–
Письмо в будущее себе пошли, потом поржеш через 10 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #34

30. Сообщение от Аноним (-), 17-Дек-12, 14:42	+2 +/–
> Установите Ubuntu Если дистрибутив трахает юзеру мозг - это еще не значит, что там используется BFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

31. Сообщение от akamit (ok), 17-Дек-12, 14:44	+1 +/–
Этого доктора уже вроде посылали, он обиделся и вот опять лезет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #36, #42

32. Сообщение от Crazy Alex (ok), 17-Дек-12, 14:44	+1 +/–
Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #38, #39

33. Сообщение от fidaj (ok), 17-Дек-12, 15:35	+/–
> Этого доктора уже вроде посылали, он обиделся и вот опять лезет. перечитай - это теперь уже другой лезет "дохтур" не все "дохтуры" одинаково полезны...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

34. Сообщение от Аноним (-), 17-Дек-12, 15:47	+2 +/–
> поржеш Вас граммар-наци расстреляют явно быстрее чем через 10 лет, если продолжите в таком же духе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

35. Сообщение от Аноним (-), 17-Дек-12, 15:49	+3 +/–
> Что можно сказать.. Все равно не примут этот шедулер в mainstream - > RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать. Ох, запилите уже свою операционку с шахматами и поэтессами и покажите этому гадкому линуксу как надо работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #49

36. Сообщение от Аноним (-), 17-Дек-12, 15:50	–1 +/–
> Этого доктора уже вроде посылали, он обиделся и вот опять лезет. А доктор кстати довольно приличный програмер. Он например написал свой майнер биткоинов. Кстати, один из лучших получился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #40

37. Сообщение от pavlinux (ok), 17-Дек-12, 16:01	+/–
1. Тема по CPU шыдулер 2. Тред про рендеринг. 3. SIMD и GPU, гы...   [сообщение отредактировано модератором]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

38. Сообщение от pavlinux (ok), 17-Дек-12, 16:12	+/–
> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует По какой такой идее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #56

39. Сообщение от pro100master (ok), 17-Дек-12, 16:24	+/–
ключевое слово *может*. Т.е. в жизни разное бывает. Когда вторые корки появились с большим кешем, наблюдал 10-кратный рост на одной задачке CGI мультитредовой (частота и пр. кроме кеша были одинаковые).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #46

40. Сообщение от Аноним (-), 17-Дек-12, 17:43	+/–
Что, кстати, намекает на уровень профессиональный уровень "профессиональных" программистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

42. Сообщение от Аноним (-), 17-Дек-12, 20:12	+1 +/–
Никто его никуда не посылал. BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит, а "персональные" рынки с низкой маржой ей не интересны. В то же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных на персональные устройства, почему-то не заинтересовались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #43, #47

43. Сообщение от fidaj (ok), 17-Дек-12, 20:46	+2 +/–
> Никто его никуда не посылал. > BTF, в общем, хорошая штука, но актуальна только для ПК и прочих > персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет > больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит, > а "персональные" рынки с низкой маржой ей не интересны. В то > же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных > на персональные устройства, почему-то не заинтересовались. Это понятно - что абсолютно универсальных вещей в природе не бывает... Терзает вопрос - ну почему каждый раз изобретают велосипеды? Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfm.../ или в Haiku http://cgit.haiku-os.org/haiku/tree/src/system/kernel/scheduler , полно и других (я говорю о тех у которых доступны исходники)... Зачем такие потуги? Или монолитность и модульность ядер уже настолько закостенела и взаимно проросла в разные подсистемы ядра что теперь простым способом нельзя отделить одно от другого? Вон в Haiku, опять-таки например, планировщик меняется почти как модуль, можно вообще скрестить два планировщика и настроить условия передачи обработки запросов на тот планировщик что нужно в данный момент и система будет вести себя адекватно при разных условиях использования и при этом оставаться интерактивной, и прекрасно масштабироваться... Что на этот счет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48, #52, #57

45. Сообщение от all_glory_to_the_hypnotoad (ok), 17-Дек-12, 21:18	+/–
ну это совсем навряд ли. Чем мельче гранулярность (т.е. low latency планеровщик), тем выше конкруренция за единицу кэша в единицу времени (~ лезет больше потоков со своими локально уникальными данными). Фактически эффективной работе кэша это тоже вредит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

46. Сообщение от all_glory_to_the_hypnotoad (ok), 17-Дек-12, 21:33	+/–
а задачка тоже в обоих случаях была мультитредовой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

47. Сообщение от linux must _RIP_ (?), 17-Дек-12, 23:53	+/–
> Никто его никуда не посылал. Да ну? а фраза линукса - что есть только один шедулер и другой нам не нужен? > BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств. Ну да. коих процентов 80 у использующих. Ну да.. зачем этот рынок линуксу? лучше иметь свой 1% красноглазых и кичится этим..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

48. Сообщение от linux must _RIP_ (?), 17-Дек-12, 23:55	–1 +/–
> Это понятно - что абсолютно универсальных вещей в природе не бывает... > Терзает вопрос - ну почему каждый раз изобретают велосипеды? > Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты > (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfm.../ Ну это же фирма зла - как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #51

49. Сообщение от linux must _RIP_ (?), 18-Дек-12, 00:01	–1 +/–
>> Что можно сказать.. Все равно не примут этот шедулер в mainstream - >> RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать. > Ох, запилите уже свою операционку с шахматами и поэтессами и покажите этому > гадкому линуксу как надо работать. Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH получает - где он один из главных акционеров.. Так что работать против своего кошелька не будет..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #54

50. Сообщение от BratSinot (?), 18-Дек-12, 01:07	–2 +/–
> переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах. Вот оно Линус-style. Я может чего не понимаю, но ОТКУДА на десктопах больше 16-ти ядер возьмется!? Ставлю 5$ что этот патч в офф ядро возьмут.
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от BratSinot (?), 18-Дек-12, 01:14	+2 +/–
> как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца.. Apple Public Source License FSF одобрена и является копилефтом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

52. Сообщение от Аноним (-), 18-Дек-12, 06:20	+/–
>Зачем такие потуги? На месте чтобы не стоять, всё правильно делают...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #58

53. Сообщение от Аноним (-), 18-Дек-12, 09:40	+1 +/–
> Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать. Напоминает ситуацию с секс-меньшинствами и их дискриминацией. "Если какой-то гoвнокод не принимают в ядро - значит, это дискриминация по признаку авторства. Надо срочно принять и извиниться!" К счастю, ядром, в отличие от некоторых государств, управляют отнюдь не долбанутые толерасты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

54. Сообщение от Аноним (-), 18-Дек-12, 09:41	+1 +/–
> Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH > получает - где он один из главных акционеров.. Завидовать нехорошо. Продолжайте чистить сортиры, авось к пенсии тоже на пару акций накопите :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

55. Сообщение от Аноним (-), 18-Дек-12, 09:43	+1 +/–
> "Brain Fuck Scheduler" > Вот почему его в основную ветку не взяли :) Несмотря на то, > что отец ядра любит комбинацию из среднего пальца крутить. Не хочу разбивать ваши воздушные замки, но не взяли просто потому, что гoвнокод. А не из-за названия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

56. Сообщение от Crazy Alex (ok), 18-Дек-12, 11:46	+/–
>> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует >  По какой такой идее? Ну как же -  чем дольше активен один поток - тем дольше нужен уму его кэш. Запустили другой - у него инструкции/данные другие - грузи заново...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #61

57. Сообщение от Аноним (-), 18-Дек-12, 13:59	+2 +/–
Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной" нагрузке проблемы того же рода, что и у BFS. Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно сказывается на отзывчивости. XNU это большая удача.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #59

58. Сообщение от fidaj (ok), 18-Дек-12, 14:06	+1 +/–
>>Зачем такие потуги? > На месте чтобы не стоять, всё правильно делают... Двигаться - это не всегда развиваться...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

59. Сообщение от fidaj (ok), 18-Дек-12, 14:08	+/–
> Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной" > нагрузке проблемы того же рода, что и у BFS. хм - поподробнее пожалуйста... > Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно > сказывается на отзывчивости. XNU это большая удача. ну на сколько я знаю - там все реализовано через планирование нитями, впрочем, как и у планировщика Haiku...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

60. Сообщение от SergMarkov (ok), 18-Дек-12, 22:51	–3 +/–
значит придется ставить от коливаса До чего не дотронутся шаловливые ручонки улучшателей становится всегда хуже, а поддержка over стопицот процев как то совершенно не упала
Ответить | Правка | Наверх | Cообщить модератору

61. Сообщение от pavlinux (ok), 19-Дек-12, 06:24	+/–
>>> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует >>  По какой такой идее? > Ну как же -  чем дольше активен один поток - тем > дольше нужен уму его кэш. Запустили другой - у него инструкции/данные > другие - грузи заново... По частоте попадания в кэш, можно судить об не оптимальности алгоритма. Если порой CACHE_HIT много, надо смотреть, чё там творится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #62

62. Сообщение от all_glory_to_the_hypnotoad (ok), 19-Дек-12, 23:18	+/–
вообще нерелевантный показатель для 'что-то там не так'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #63

63. Сообщение от pavlinux (ok), 21-Дек-12, 16:50	–1 +/–
> вообще нерелевантный показатель для 'что-то там не так' if (a > 10 )      x + a; else if (a > 200 )      x + a + 2; else if (a > 50 )      x + a + 3; else if (a > 100)      x + a + 4; else if (a > 1000 )      x + a + 5; Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #64

64. Сообщение от Led (ok), 22-Дек-12, 02:57	+/–
>[оверквотинг удален] >      x + a; > else if (a > 200 ) >      x + a + 2; > else if (a > 50 ) >      x + a + 3; > else if (a > 100) >      x + a + 4; > else if (a > 1000 ) >      x + a + 5; > Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так). Нет такого файла в ядре - наверное ты сам его и дописал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #65

65. Сообщение от pavlinux (ok), 22-Дек-12, 18:57	+/–
>[оверквотинг удален] > Нет такого файла в ядре - наверное ты сам его и дописал? А то, сижу пешу 2.6 - 2.6.23 arch/i386/pci/mmconfig.c arch/i386/pci/mmconfig-shared.c arch/x86_64/pci/mmconfig.c 2.6.24 - 3.7   arch/x86/pci/mmconfig_64.c arch/x86/pci/mmconfig_32.c arch/x86/pci/mmconfig-shared.c
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #66

66. Сообщение от Led (ok), 22-Дек-12, 22:10	+/–
> 2.6.24 - 3.7 > arch/x86/pci/mmconfig_64.c > arch/x86/pci/mmconfig_32.c > arch/x86/pci/mmconfig-shared.c Эти файлы есть. Но представленного тобой кода в них нет. Значит этот быдлокод таки ты сам и дописываешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #67

67. Сообщение от pavlinux (ok), 22-Дек-12, 22:24	+/–
> Значит этот быдлокод таки ты сам и дописываешь? нужно - найдешь, ориентир MMCONFIG
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #68

68. Сообщение от Led (ok), 23-Дек-12, 00:00	+/–
>> Значит этот быдлокод таки ты сам и дописываешь? > нужно - найдешь, ориентир MMCONFIG Я по всему дереву исходников грепал - нет в ядре такого кода
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #69

69. Сообщение от pavlinux (ok), 23-Дек-12, 03:13	+/–
>>> Значит этот быдлокод таки ты сам и дописываешь? >> нужно - найдешь, ориентир MMCONFIG > Я по всему дереву исходников грепал - нет в ядре такого кода Конечно нет. А кто говорил, что этот код из ядра?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #70, #71

70. Сообщение от fidaj (ok), 23-Дек-12, 13:27	+/–
>>>> Значит этот быдлокод таки ты сам и дописываешь? >>> нужно - найдешь, ориентир MMCONFIG >> Я по всему дереву исходников грепал - нет в ядре такого кода > Конечно нет. А кто говорил, что этот код из ядра? удивительные иногда диалоги на опеннете... "Сообщение от pavlinux (ok) on 21-Дек-12, 16:50     > вообще нерелевантный показатель для 'что-то там не так'     if (a > 10 )          x + a;     else if (a > 200 )          x + a + 2;     else if (a > 50 )          x + a + 3;     else if (a > 100)          x + a + 4;     else if (a > 1000 )          x + a + 5;     Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так)."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

71. Сообщение от Led (ok), 23-Дек-12, 21:40	+/–
>>>> Значит этот быдлокод таки ты сам и дописываешь? >>> нужно - найдешь, ориентир MMCONFIG >> Я по всему дереву исходников грепал - нет в ядре такого кода > Конечно нет. А кто говорил, что этот код из ядра? Ты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

72. Сообщение от Anonim2023 (?), 11-Дек-23, 12:44	+/–
2023 на дворе, 32 потока в домашних процессорах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема