forum.opennet.ru - "Новый шаг по интеграции в Linux ядро RealTime-расширений" (33)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Новый шаг по интеграции в Linux ядро RealTime-расширений"

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

"Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
Сообщение от opennews on 10-Фев-10, 16:58
До сих пор, в основной ветке Linux, использовался только один тип спилок-блокировок (http://ru.wikipedia.org/wiki/%D0%A1%D0%B...) - «вращающиеся» спинлоки (spinning spinlocks). Однако, в дереве PREEMPT_RT, они должны быть дифференцированы между спинлоками которые могут «засыпать» в режиме реального времени и обычными спинлоками, даже в режиме реального времени. Это требует нового пространства имен и решения, какой тип спинлоков переименовать. На конференции Kernel Summit 2009, было решено (http://www.osadl.org/Single-View.111+M58050282514.0.html) не переименовывать блокировки, которые должны быть преобразованы в «засыпающие» спинлоки в дереве PREEMPT_RT, поскольку это привело бы к огромному количеству патчей и, безусловно, создало бы путаницу. Позднее, в заключительной стадии слияния Linux 2.6.33, Линус выступил с предложением: - Переименовать архитектуру реализаций спинлоков от raw_spinlock к arch_spinlock. - И... URL: http://www.osadl.org/Single-View.111+M58050282514.0.html Новость: http://www.opennet.me/opennews/art.shtml?num=25366
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Новый шаг по интеграции в Linux ядро RealTime-расширений, Zenitur, 16:58 , 10-Фев-10, (1)

Новый шаг по интеграции в Linux ядро RealTime-расширений, anonimus, 17:23 , 10-Фев-10, (5) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, devl547, 20:12 , 10-Фев-10, (17) –1

Новый шаг по интеграции в Linux ядро RealTime-расширений, anonimus, 20:16 , 10-Фев-10, (18) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, Basiley, 03:26 , 11-Фев-10, (26)

Новый шаг по интеграции в Linux ядро RealTime-расширений, Аноним, 16:58 , 10-Фев-10, (2)
Новый шаг по интеграции в Linux ядро RealTime-расширений, Аноним, 17:16 , 10-Фев-10, (3) –7

Новый шаг по интеграции в Linux ядро RealTime-расширений, Tav, 17:41 , 10-Фев-10, (6) +6
Новый шаг по интеграции в Linux ядро RealTime-расширений, аноним, 17:44 , 10-Фев-10, (7)

Новый шаг по интеграции в Linux ядро RealTime-расширений, НоуНэйм, 02:21 , 11-Фев-10, (24) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, KaLGaN, 18:41 , 10-Фев-10, (10) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, Basiley, 03:27 , 11-Фев-10, (27)

Новый шаг по интеграции в Linux ядро RealTime-расширений, prox, 13:06 , 15-Фев-10, (36)

Новый шаг по интеграции в Linux ядро RealTime-расширений, Аноним, 17:19 , 10-Фев-10, (4) +1
Новый шаг по интеграции в Linux ядро RealTime-расширений, друг XoRe, 18:41 , 10-Фев-10, (11)

Новый шаг по интеграции в Linux ядро RealTime-расширений, uZver, 19:09 , 10-Фев-10, (13)
Новый шаг по интеграции в Linux ядро RealTime-расширений, User294, 19:48 , 10-Фев-10, (16)

Новый шаг по интеграции в Linux ядро RealTime-расширений, KdF, 20:44 , 10-Фев-10, (19) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, User294, 10:56 , 11-Фев-10, (30) –1

Новый шаг по интеграции в Linux ядро RealTime-расширений, KdF, 02:48 , 12-Фев-10, (32)

Новый шаг по интеграции в Linux ядро RealTime-расширений, anonymous, 15:46 , 12-Фев-10, (34)

Новый шаг по интеграции в Linux ядро RealTime-расширений, KdF, 15:20 , 14-Фев-10, (35)

Новый шаг по интеграции в Linux ядро RealTime-расширений, anonymous, 16:53 , 15-Фев-10, (37)

Новый шаг по интеграции в Linux ядро RealTime-расширений, Tav, 21:39 , 10-Фев-10, (20)

Новый шаг по интеграции в Linux ядро RealTime-расширений, User294, 10:58 , 11-Фев-10, (31) –4

Новый шаг по интеграции в Linux ядро RealTime-расширений, aZ, 03:33 , 12-Фев-10, (33)

Новый шаг по интеграции в Linux ядро RealTime-расширений, anonymous vulgaris, 21:40 , 10-Фев-10, (21) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, Nick, 19:00 , 10-Фев-10, (12)

Новый шаг по интеграции в Linux ядро RealTime-расширений, pavlinux, 19:10 , 10-Фев-10, (14) –1

Новый шаг по интеграции в Linux ядро RealTime-расширений, друг XoRe, 22:55 , 10-Фев-10, (22) –2

Новый шаг по интеграции в Linux ядро RealTime-расширений, pavlinux, 03:43 , 11-Фев-10, (28) +1

Новый шаг по интеграции в Linux ядро RealTime-расширений, аноним, 02:09 , 11-Фев-10, (23)

Новый шаг по интеграции в Linux ядро RealTime-расширений, pavlinux, 03:06 , 11-Фев-10, (25)

Сообщения по теме [Сортировка по времени | RSS]

1. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Zenitur on 10-Фев-10, 16:58

И это здорово!
одно из применений RT-ядра - студии звукозаписи. Во всех ориентированных на это дистрибутивах только RT-ядро.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от anonimus on 10-Фев-10, 17:23

Да, но только оно не всегда спасает, когда дело упирается в планировщик ввода/вывода - все со звуком начинает кавкать, икать и заикаться...
Попробуйте в Ardour пару десятков треков с эффектами покрутить...
Надеюсь, что эти нововведения хоть как-то поправят положение дел в лучшую сторону...
Хотя с планировщиком тоже что-то нужно делать, уже с 24-го RT ядра тянется это все дело...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –1 +/–

Сообщение от devl547 on 10-Фев-10, 20:12

>планировщик ввода/вывода
BFQ/NOOP/SIO - попробуйте, может что поможет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от anonimus on 10-Фев-10, 20:16

>>планировщик ввода/вывода
>
>BFQ/NOOP/SIO - попробуйте, может что поможет.
Вы наверное хотели сказать cfq anticipatory deadline noop
пробовал все - проблема не разрешается...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Basiley (ok) on 11-Фев-10, 03:26

попробуйте поиграться с ionice.
к сожаленю текущая версия reniced - рулит только планирвоащиками CPU(без IO).
мб выйдет аналог.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Аноним (??) on 10-Фев-10, 16:58

"Томас Глейкснер создал серию патчей, которые Линус включил в ядро 2.6.33." - как же это кажется приятным.
тестировал летом, помнится что были проблемы в 2.6.31 с виртуалбоксом - интересно что получится..

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –7 +/–

Сообщение от Аноним (??) on 10-Фев-10, 17:16

>одно из применений RT-ядра - студии звукозаписи.
Зачем оно этим студиям такое реалтаймовое ядро понадобилось, под которое музыкального софта то и нет нормального.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +6 +/–

Сообщение от Tav (ok) on 10-Фев-10, 17:41

Кому нет, а кто вовсю использует.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от аноним on 10-Фев-10, 17:44

> под которое музыкального софта то и нет нормального
Вы шутите?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от НоуНэйм on 11-Фев-10, 02:21

нет. он троллит.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от KaLGaN on 10-Фев-10, 18:41

http://ubuntustudio.org/

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Basiley (ok) on 11-Фев-10, 03:27

>http://ubuntustudio.org/
есть посерьезнее(и постарше)MM-дистры.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

36. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от prox (ok) on 15-Фев-10, 13:06

Какие например?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от Аноним (??) on 10-Фев-10, 17:19

Често не понимаю суть новости. Так какими-же должны быть спинлоки в режиме реального времени? Те что засыпают уже вряд-ли можно назвать спинлоками. Это скорее уже семафоры.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от друг XoRe on 10-Фев-10, 18:41

что-то я не совсем пойму, помогите: ядро Linux работает со свап пространством, о какой  реал тайм может идти речь? или это про встроенные системы? допуская что в "мягком" виде,но не в "жестком"  еще можно прогнозировать выполнение задачи на время загруки выгрузки(время) swap контекста.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от uZver (??) on 10-Фев-10, 19:09

а если не допускать работы со свапом? заблокать его к примеру? ядро без RT-патчей все равно не будет реал-таймовым...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от User294 (ok) on 10-Фев-10, 19:48

Я что-то не вдупляю: что мешает не пользоваться свопом? А так - по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну, будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)
ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от KdF (??) on 10-Фев-10, 20:44

>Я что-то не вдупляю: что мешает не пользоваться свопом? А так -
>по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну,
>будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)
>
>
>ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти. Всякое lru туда скидывает и радуется, освобождая память. Другое дело, что если не будет свопа, он просто не будет этого делать.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –1 +/–

Сообщение от User294 (ok) on 11-Фев-10, 10:56

> Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти
Простите, а вы это в теории проверяли или на практике?
По шагам:
1) Берем машину с достаточным размером оперативы чтобы в нее лезло все (ну допустим 4..8 гигз для десктопа со всеми наворотами).
2) Цепляем своп.
3) Юзаем.
4) Посматриваем на юзеж памяти и свопа.
5) Постепенно засираем память.
6)  Особенно активно смотрим на состояние свопа когда выжранное приближается к размеру оперативы.
Что как правило видим? Пока свободной памяти много - своп вообще линуху перпендикулярен. Туда не льется ни-че-го. В нем лежит какие-то несколько килобай. И ... все. Поэтому переключение между разными увесистыми апликухами вообще не тормозит до тех пор пока все запущенное лезет в физическую оперативку. Когда лезть перестает - начинается отлив в своп того что давно не использовалось. Да, ессно тормоза начинаются но это хороший сигнал что что-то идет не так и кто-то из процессов пошел вразнос и суммарный жрач начинает превышать физическую память. Данный стиль поведения наблюдался на кучке разных пингвинов. Попробуйте сами так поэкспериментировать да посмотите. Если что так себя вели как минимум ядра от .18 до .31
> Другое дело, что если не будет свопа, он просто не будет этого делать.
Самое интересное - что этого не делается и когда своп есть, пока памяти хватает. Сие кстати выгодно отличает линухи от виндов. В винде действительно давно не использованное добро в своп сливается в фоне. И достаточно нагло и активно, невзирая на объемы свободной памяти и прочая. В итоге - переключение между увесистыми процессами тарахтит диском. Так что если вы сунулись в файрфокс, а потом в VS, а потом в Outlook а потом в Ворд, поработав в каждой софтине полчаса - вы рискуете при каждом переключении раз в полчаса столкнуться с натужным хрустением диска. При этом пофиг что половина оперативы еще свободна, много дряни сольется в своп все-равно. Под линухами такое не проявляется и своп в подобной ситуации пуст и ничего не тормозит вплоть до момента когда с оперативкой станет реально душно. Так, всего лишь скромное наблюдение над логикой работы свопления реально существующих ОС в реальных условиях их использования.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от KdF (??) on 12-Фев-10, 02:48

Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.
Я не знаю, какими дистрибутивами вы пользуетесь, но ситуация, которую вы описываете, как раз характерна для неправильной работы механизма распределения памяти. Выкинуть в своп - всегда правильное решение для least recently used данных, особенно на сервере. При недостатке памяти первым делом он покиляет дисковые кэши, а уж потом начнет выгружать в своп страницы.
Если вы дергаете постоянно приложения, переключаясь между ними, очевидно, что грамотный менеджер памяти не будет выкидывать их в своп, возможно, именно про это отличие от windows вы говорите. Но понятно, что выкинуть страницы софта, отожравшего три дня назад 300 Мб памяти и не обращавшегося к ним, для ускорения интенсивного обмена с диском той же самой MySQL или для потребностей другого ресурсоемкого приложения - прямая обязанность диспетчера памяти.
Также учитывайте механизм выделения памяти приложению в Linux - приложению по факту выделения количество памяти не гарантируется, это не физические страницы, а страницы выдаются по попытке доступа к ним. overcommit + swapiness, рекомендую обратить внимание. Чтобы в один прекрасный день не обнаружить сервис, который выжрал 8 Гб якобы имеющейся в системе без свопа памяти, которая на самом-то деле уже распределена ;)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

34. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от anonymous (??) on 12-Фев-10, 15:46

>Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов
>памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.
А г-ди, исходники ядра.. google://vm.swappiness vm.vfs_cache_pressure, насчет oom killer с компанией — vm.overcommit_memory vm.oom_kill_allocating_task vm.overcommit_ratio
Врядли вам нужно больше.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

35. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от KdF (??) on 14-Фев-10, 15:20

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от anonymous (??) on 15-Фев-10, 16:53

>vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу
>данных при имеющейся свободной памяти как относятся?
vm.swappiness вроде бы непосредственно, а остальные к oom же

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Tav (ok) on 10-Фев-10, 21:39

> по моим наблюдениям линух юзает своп лишь когда реально припирает
По умолчанию это не так. Но можно настроить (значение в /proc/sys/vm/swappiness).
А RT-приложения все равно используют memlock, если пользователю разрешено.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –4 +/–

Сообщение от User294 (ok) on 11-Фев-10, 10:58

>По умолчанию это не так.
В каких ядрах, ос и прочая? В ванилле какойнить? А то попавшиеся под руку "десктопные" линухи вели себя именно описанным мной образом - своп обычно пустой пока не начнет натурально прижимать :).Да и на серверных что-то не видел отлива в своп пока душняк не наступил. Что я делаю не так? oO

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от aZ (ok) on 12-Фев-10, 03:33

Похоже, что ты вообще мало имел дел с линуксом. Только троллить горазд на опеннете.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от anonymous vulgaris on 10-Фев-10, 21:40

>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
Риал тайм жаба не собирает мусор когда не надо
http://java.sun.com/javase/technologies/realtime/index.jsp
New Memory Management Schemes
Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference.
но есть мусорщики с детерминированным поведением
Metronome is a deterministic garbage collector that offers bounded low pause times and specified application utilization for standard Java applications.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от Nick (??) on 10-Фев-10, 19:00

Свап можно выключить, что нормально для встраиваемых систем. А как обстоят дела с десктопными решениями?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –1 +/–

Сообщение от pavlinux (ok) on 10-Фев-10, 19:10

И вообще, swap и реалтайм никому не мешают ...
Реалтайм проги пишут с запрещением выгрузки в shared mem

#include <sys/resource.h>

struct rlimit limit;
limit.rlim_cur = 0;
limit.rlim_max = 0;
setrlimit(RLIMIT_CORE, &limit); // не выдавать кору
long pagesize = sysconf(_SC_PAGESIZE); // страничка для млока
char *buf;
char *data;
buf =  (char *)malloc(size+1+pagesize);
data = (char *)((((intptr_t)buf + pagesize - 1) / pagesize) * pagesize);
setvbuf(data, (char *) NULL, _IONBF, 0);
mlock(data, size+1);
// Работаем
munlock(data, size+1);
free(buf);

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Новый шаг по интеграции в Linux ядро RealTime-расширений" –2 +/–

Сообщение от друг XoRe on 10-Фев-10, 22:55

нет, не согласен в книги FreeBSD. Архитектура и реализация. Невил-нил Д. В., Маккузик М. К
имеено проблема была со свапом, поэтому FreeBSD не может работать как real-time система + ОЧЕНЬ БОЛЬШОЙ ВОПРОС TCP/IP как будете прогнозировать точное время выполения задачи?????????????????????????? так что реализация, только для локальной хоста, не более (причем без сваппа) и скорее всего без некоторых системных процессов, например будет потеря кол-ва времени (тиков) для ругих процессов (системынх и пользовательсикх) так как весь cpu будет отдан под задачу real-time, что скореевсего скажется на целостности системы,из-за невозможности отдать время системному процессу. Хотя согласен, для систем "мягкого реального времени" планировщик пойдет, для жесткого нет -  ответ системы не детерминирован.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +1 +/–

Сообщение от pavlinux (ok) on 11-Фев-10, 03:43

>нет, не согласен в книги FreeBSD. Архитектура и реализация. Невил-нил Д. В.,
>Маккузик М. К имеено проблема была со свапом, поэтому FreeBSD не может
> работать как real-time система + ОЧЕНЬ БОЛЬШОЙ ВОПРОС TCP/IP
Хоть в одном стандарте на TCP/IP есть временные константы ??? Ну а хрен тогда...
> как будете прогнозировать точное время выполения задачи??????????????????????????
Маккузик крутой наверно перец, что даже не учёл понятия "СИСТЕМА"!!!
Никто против не будет если я любую сеть обзову системой?! Нет!
Имеем минимум два хоста соединённые в сеть, [X] --- [Y],
поднимите чё-нить, кто за то, что эту ситему можно назвать REAL-TIME, только
при условии, что ОБА ЭЛЕМЕНТА СИСТЕМЫ ЯВЛЯЮТСЯ REAL-TIME?!

  RT = (X c RT) + ( Y c RT )
По-русски - Множество RT полно, тогда и только тогда, когда каждый элемент подмножества принадлежит этому множеству.
Так какой в попу реал тайм, если даже не известно придет ли пинг обратно,
скажем из Чили, или со спутника.
Всё ещё против?!  Ну тогда другая система - SOFTWARE <-> HARDWARE
Кто за то, что QNX и vxWorks станут ацтойными операционками, если
у RTC будет погрешность в 25%?! То есть с вероятностью 0.001,
за 4 реальные секунды он убежит или затормозит на 1 секунду.

> так что реализация, только для локальной хоста,  не более (причем без сваппа)
> и скорее всего без некоторых системных процессов, например
> будет потеря кол-ва времени (тиков) для других процессов (системных и пользовательских)
> так как весь cpu будет отдан под задачу real-time, что скорее всего
> скажется на целостности системы,из-за невозможности отдать время системному процессу.
> Хотя согласен, для систем "мягкого реального времени" планировщик пойдет,
> для жесткого нет - ответ системы не детерминирован.
Детерминированность...
Хе, а что такое время?! 9 мульёнов периодов полураспада какого-то там изпопа Цезия?
Тут доказали, что скорость света не постоянна, а вы про время...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от аноним on 11-Фев-10, 02:09

>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!
Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не  новом шаге, а в том, что разгребают старые ошибки, когда ядро изначально не было реалтайм. Уменьшение патча на 350 Кб - это, безусловно, прорыв!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Новый шаг по интеграции в Linux ядро RealTime-расширений" +/–

Сообщение от pavlinux (ok) on 11-Фев-10, 03:06

>>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!
>
>Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не
> новом шаге, а в том, что разгребают старые ошибки, когда
>ядро изначально не было реалтайм. Уменьшение патча на 350 Кб -
>это, безусловно, прорыв!
http://www.osadl.org/Single-View.111+M58050282514.0.html
"This reduced the size of the preempt-rt patch by 350 kByte -
another important milestone on our road towards complete
integration of the RT tree into the mainline kernel!"

important milestone, важный этап или веха...
ЭТАП применимо к событиям которые будут известны в будущем, т.е. переменным
перечислимого типа, при исторической оценке событий, когда события явно
можно делить на части.
Слово же ВЕХА, нихрена не определенного типа, void говоря по-нашему :)
Ибо что будя завтра, не знает даже "то, чаво не может быть".

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
Сообщение от Zenitur on 10-Фев-10, 16:58
И это здорово! одно из применений RT-ядра - студии звукозаписи. Во всех ориентированных на это дистрибутивах только RT-ядро.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от anonimus on 10-Фев-10, 17:23
	Да, но только оно не всегда спасает, когда дело упирается в планировщик ввода/вывода - все со звуком начинает кавкать, икать и заикаться... Попробуйте в Ardour пару десятков треков с эффектами покрутить... Надеюсь, что эти нововведения хоть как-то поправят положение дел в лучшую сторону... Хотя с планировщиком тоже что-то нужно делать, уже с 24-го RT ядра тянется это все дело...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	17. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–1 +/–
	Сообщение от devl547 on 10-Фев-10, 20:12
	>планировщик ввода/вывода BFQ/NOOP/SIO - попробуйте, может что поможет.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	18. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от anonimus on 10-Фев-10, 20:16
	>>планировщик ввода/вывода > >BFQ/NOOP/SIO - попробуйте, может что поможет. Вы наверное хотели сказать cfq anticipatory deadline noop пробовал все - проблема не разрешается...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	26. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от Basiley (ok) on 11-Фев-10, 03:26
	попробуйте поиграться с ionice. к сожаленю текущая версия reniced - рулит только планирвоащиками CPU(без IO). мб выйдет аналог.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

2. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
Сообщение от Аноним (??) on 10-Фев-10, 16:58
"Томас Глейкснер создал серию патчей, которые Линус включил в ядро 2.6.33." - как же это кажется приятным. тестировал летом, помнится что были проблемы в 2.6.31 с виртуалбоксом - интересно что получится..
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

3. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–7 +/–
Сообщение от Аноним (??) on 10-Фев-10, 17:16
>одно из применений RT-ядра - студии звукозаписи. Зачем оно этим студиям такое реалтаймовое ядро понадобилось, под которое музыкального софта то и нет нормального.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+6 +/–
	Сообщение от Tav (ok) on 10-Фев-10, 17:41
	Кому нет, а кто вовсю использует.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от аноним on 10-Фев-10, 17:44
	> под которое музыкального софта то и нет нормального Вы шутите?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	24. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от НоуНэйм on 11-Фев-10, 02:21
	нет. он троллит.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	10. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от KaLGaN on 10-Фев-10, 18:41
	http://ubuntustudio.org/
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	27. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от Basiley (ok) on 11-Фев-10, 03:27
	>http://ubuntustudio.org/ есть посерьезнее(и постарше)MM-дистры.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	36. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от prox (ok) on 15-Фев-10, 13:06
	Какие например?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

4. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
Сообщение от Аноним (??) on 10-Фев-10, 17:19
Често не понимаю суть новости. Так какими-же должны быть спинлоки в режиме реального времени? Те что засыпают уже вряд-ли можно назвать спинлоками. Это скорее уже семафоры.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

11. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
Сообщение от друг XoRe on 10-Фев-10, 18:41
что-то я не совсем пойму, помогите: ядро Linux работает со свап пространством, о какой реал тайм может идти речь? или это про встроенные системы? допуская что в "мягком" виде,но не в "жестком" еще можно прогнозировать выполнение задачи на время загруки выгрузки(время) swap контекста.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	13. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от uZver (??) on 10-Фев-10, 19:09
	а если не допускать работы со свапом? заблокать его к примеру? ядро без RT-патчей все равно не будет реал-таймовым...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	16. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от User294 (ok) on 10-Фев-10, 19:48
	Я что-то не вдупляю: что мешает не пользоваться свопом? А так - по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну, будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :) ЗЫ павлин вон написал более цивильный пример борьбы с пакостями. ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	19. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от KdF (??) on 10-Фев-10, 20:44
	>Я что-то не вдупляю: что мешает не пользоваться свопом? А так - >по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну, >будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :) > > >ЗЫ павлин вон написал более цивильный пример борьбы с пакостями. >ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :) Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти. Всякое lru туда скидывает и радуется, освобождая память. Другое дело, что если не будет свопа, он просто не будет этого делать.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	30. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–1 +/–
	Сообщение от User294 (ok) on 11-Фев-10, 10:56
	> Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти Простите, а вы это в теории проверяли или на практике? По шагам: 1) Берем машину с достаточным размером оперативы чтобы в нее лезло все (ну допустим 4..8 гигз для десктопа со всеми наворотами). 2) Цепляем своп. 3) Юзаем. 4) Посматриваем на юзеж памяти и свопа. 5) Постепенно засираем память. 6) Особенно активно смотрим на состояние свопа когда выжранное приближается к размеру оперативы. Что как правило видим? Пока свободной памяти много - своп вообще линуху перпендикулярен. Туда не льется ни-че-го. В нем лежит какие-то несколько килобай. И ... все. Поэтому переключение между разными увесистыми апликухами вообще не тормозит до тех пор пока все запущенное лезет в физическую оперативку. Когда лезть перестает - начинается отлив в своп того что давно не использовалось. Да, ессно тормоза начинаются но это хороший сигнал что что-то идет не так и кто-то из процессов пошел вразнос и суммарный жрач начинает превышать физическую память. Данный стиль поведения наблюдался на кучке разных пингвинов. Попробуйте сами так поэкспериментировать да посмотите. Если что так себя вели как минимум ядра от .18 до .31 > Другое дело, что если не будет свопа, он просто не будет этого делать. Самое интересное - что этого не делается и когда своп есть, пока памяти хватает. Сие кстати выгодно отличает линухи от виндов. В винде действительно давно не использованное добро в своп сливается в фоне. И достаточно нагло и активно, невзирая на объемы свободной памяти и прочая. В итоге - переключение между увесистыми процессами тарахтит диском. Так что если вы сунулись в файрфокс, а потом в VS, а потом в Outlook а потом в Ворд, поработав в каждой софтине полчаса - вы рискуете при каждом переключении раз в полчаса столкнуться с натужным хрустением диска. При этом пофиг что половина оперативы еще свободна, много дряни сольется в своп все-равно. Под линухами такое не проявляется и своп в подобной ситуации пуст и ничего не тормозит вплоть до момента когда с оперативкой станет реально душно. Так, всего лишь скромное наблюдение над логикой работы свопления реально существующих ОС в реальных условиях их использования.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	32. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от KdF (??) on 12-Фев-10, 02:48
	Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко. Я не знаю, какими дистрибутивами вы пользуетесь, но ситуация, которую вы описываете, как раз характерна для неправильной работы механизма распределения памяти. Выкинуть в своп - всегда правильное решение для least recently used данных, особенно на сервере. При недостатке памяти первым делом он покиляет дисковые кэши, а уж потом начнет выгружать в своп страницы. Если вы дергаете постоянно приложения, переключаясь между ними, очевидно, что грамотный менеджер памяти не будет выкидывать их в своп, возможно, именно про это отличие от windows вы говорите. Но понятно, что выкинуть страницы софта, отожравшего три дня назад 300 Мб памяти и не обращавшегося к ним, для ускорения интенсивного обмена с диском той же самой MySQL или для потребностей другого ресурсоемкого приложения - прямая обязанность диспетчера памяти. Также учитывайте механизм выделения памяти приложению в Linux - приложению по факту выделения количество памяти не гарантируется, это не физические страницы, а страницы выдаются по попытке доступа к ним. overcommit + swapiness, рекомендую обратить внимание. Чтобы в один прекрасный день не обнаружить сервис, который выжрал 8 Гб якобы имеющейся в системе без свопа памяти, которая на самом-то деле уже распределена ;)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	34. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от anonymous (??) on 12-Фев-10, 15:46
	>Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов >памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко. А г-ди, исходники ядра.. google://vm.swappiness vm.vfs_cache_pressure, насчет oom killer с компанией — vm.overcommit_memory vm.oom_kill_allocating_task vm.overcommit_ratio Врядли вам нужно больше.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	35. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от KdF (??) on 14-Фев-10, 15:20
	vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу данных при имеющейся свободной памяти как относятся?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	37. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от anonymous (??) on 15-Фев-10, 16:53
	>vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу >данных при имеющейся свободной памяти как относятся? vm.swappiness вроде бы непосредственно, а остальные к oom же
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	20. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от Tav (ok) on 10-Фев-10, 21:39
	> по моим наблюдениям линух юзает своп лишь когда реально припирает По умолчанию это не так. Но можно настроить (значение в /proc/sys/vm/swappiness). А RT-приложения все равно используют memlock, если пользователю разрешено.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	31. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–4 +/–
	Сообщение от User294 (ok) on 11-Фев-10, 10:58
	>По умолчанию это не так. В каких ядрах, ос и прочая? В ванилле какойнить? А то попавшиеся под руку "десктопные" линухи вели себя именно описанным мной образом - своп обычно пустой пока не начнет натурально прижимать :).Да и на серверных что-то не видел отлива в своп пока душняк не наступил. Что я делаю не так? oO
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	33. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
	Сообщение от aZ (ok) on 12-Фев-10, 03:33
	Похоже, что ты вообще мало имел дел с линуксом. Только троллить горазд на опеннете.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	21. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+1 +/–
	Сообщение от anonymous vulgaris on 10-Фев-10, 21:40
	>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :) Риал тайм жаба не собирает мусор когда не надо http://java.sun.com/javase/technologies/realtime/index.jsp New Memory Management Schemes Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference. но есть мусорщики с детерминированным поведением Metronome is a deterministic garbage collector that offers bounded low pause times and specified application utilization for standard Java applications.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

12. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		+/–
Сообщение от Nick (??) on 10-Фев-10, 19:00
Свап можно выключить, что нормально для встраиваемых систем. А как обстоят дела с десктопными решениями?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	14. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–1 +/–
	Сообщение от pavlinux (ok) on 10-Фев-10, 19:10
	И вообще, swap и реалтайм никому не мешают ... Реалтайм проги пишут с запрещением выгрузки в shared mem #include <sys/resource.h> struct rlimit limit; limit.rlim_cur = 0; limit.rlim_max = 0; setrlimit(RLIMIT_CORE, &limit); // не выдавать кору long pagesize = sysconf(_SC_PAGESIZE); // страничка для млока char buf; char data; buf = (char )malloc(size+1+pagesize); data = (char )((((intptr_t)buf + pagesize - 1) / pagesize) * pagesize); setvbuf(data, (char *) NULL, _IONBF, 0); mlock(data, size+1); // Работаем munlock(data, size+1); free(buf);
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	22. "Новый шаг по интеграции в Linux ядро RealTime-расширений"		–2 +/–
	Сообщение от друг XoRe on 10-Фев-10, 22:55
	нет, не согласен в книги FreeBSD. Архитектура и реализация. Невил-нил Д. В., Маккузик М. К имеено проблема была со свапом, поэтому FreeBSD не может работать как real-time система + ОЧЕНЬ БОЛЬШОЙ ВОПРОС TCP/IP как будете прогнозировать точное время выполения задачи?????????????????????????? так что реализация, только для локальной хоста, не более (причем без сваппа) и скорее всего без некоторых системных процессов, например будет потеря кол-ва времени (тиков) для ругих процессов (системынх и пользовательсикх) так как весь cpu будет отдан под задачу real-time, что скореевсего скажется на целостности системы,из-за невозможности отдать время системному процессу. Хотя согласен, для систем "мягкого реального времени" планировщик пойдет, для жесткого нет - ответ системы не детерминирован.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору