До сих пор, в основной ветке 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
И это здорово!
одно из применений RT-ядра - студии звукозаписи. Во всех ориентированных на это дистрибутивах только RT-ядро.
Да, но только оно не всегда спасает, когда дело упирается в планировщик ввода/вывода - все со звуком начинает кавкать, икать и заикаться...
Попробуйте в Ardour пару десятков треков с эффектами покрутить...
Надеюсь, что эти нововведения хоть как-то поправят положение дел в лучшую сторону...
Хотя с планировщиком тоже что-то нужно делать, уже с 24-го RT ядра тянется это все дело...
>планировщик ввода/выводаBFQ/NOOP/SIO - попробуйте, может что поможет.
>>планировщик ввода/вывода
>
>BFQ/NOOP/SIO - попробуйте, может что поможет.Вы наверное хотели сказать cfq anticipatory deadline noop
пробовал все - проблема не разрешается...
попробуйте поиграться с ionice.
к сожаленю текущая версия reniced - рулит только планирвоащиками CPU(без IO).
мб выйдет аналог.
"Томас Глейкснер создал серию патчей, которые Линус включил в ядро 2.6.33." - как же это кажется приятным.
тестировал летом, помнится что были проблемы в 2.6.31 с виртуалбоксом - интересно что получится..
>одно из применений RT-ядра - студии звукозаписи.Зачем оно этим студиям такое реалтаймовое ядро понадобилось, под которое музыкального софта то и нет нормального.
Кому нет, а кто вовсю использует.
> под которое музыкального софта то и нет нормальногоВы шутите?
нет. он троллит.
http://ubuntustudio.org/
>http://ubuntustudio.org/есть посерьезнее(и постарше)MM-дистры.
Какие например?
Често не понимаю суть новости. Так какими-же должны быть спинлоки в режиме реального времени? Те что засыпают уже вряд-ли можно назвать спинлоками. Это скорее уже семафоры.
что-то я не совсем пойму, помогите: ядро Linux работает со свап пространством, о какой реал тайм может идти речь? или это про встроенные системы? допуская что в "мягком" виде,но не в "жестком" еще можно прогнозировать выполнение задачи на время загруки выгрузки(время) swap контекста.
а если не допускать работы со свапом? заблокать его к примеру? ядро без RT-патчей все равно не будет реал-таймовым...
Я что-то не вдупляю: что мешает не пользоваться свопом? А так - по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну, будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
>Я что-то не вдупляю: что мешает не пользоваться свопом? А так -
>по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну,
>будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)
>
>
>ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти. Всякое lru туда скидывает и радуется, освобождая память. Другое дело, что если не будет свопа, он просто не будет этого делать.
> Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памятиПростите, а вы это в теории проверяли или на практике?
По шагам:
1) Берем машину с достаточным размером оперативы чтобы в нее лезло все (ну допустим 4..8 гигз для десктопа со всеми наворотами).
2) Цепляем своп.
3) Юзаем.
4) Посматриваем на юзеж памяти и свопа.
5) Постепенно засираем память.
6) Особенно активно смотрим на состояние свопа когда выжранное приближается к размеру оперативы.Что как правило видим? Пока свободной памяти много - своп вообще линуху перпендикулярен. Туда не льется ни-че-го. В нем лежит какие-то несколько килобай. И ... все. Поэтому переключение между разными увесистыми апликухами вообще не тормозит до тех пор пока все запущенное лезет в физическую оперативку. Когда лезть перестает - начинается отлив в своп того что давно не использовалось. Да, ессно тормоза начинаются но это хороший сигнал что что-то идет не так и кто-то из процессов пошел вразнос и суммарный жрач начинает превышать физическую память. Данный стиль поведения наблюдался на кучке разных пингвинов. Попробуйте сами так поэкспериментировать да посмотите. Если что так себя вели как минимум ядра от .18 до .31
> Другое дело, что если не будет свопа, он просто не будет этого делать.
Самое интересное - что этого не делается и когда своп есть, пока памяти хватает. Сие кстати выгодно отличает линухи от виндов. В винде действительно давно не использованное добро в своп сливается в фоне. И достаточно нагло и активно, невзирая на объемы свободной памяти и прочая. В итоге - переключение между увесистыми процессами тарахтит диском. Так что если вы сунулись в файрфокс, а потом в VS, а потом в Outlook а потом в Ворд, поработав в каждой софтине полчаса - вы рискуете при каждом переключении раз в полчаса столкнуться с натужным хрустением диска. При этом пофиг что половина оперативы еще свободна, много дряни сольется в своп все-равно. Под линухами такое не проявляется и своп в подобной ситуации пуст и ничего не тормозит вплоть до момента когда с оперативкой станет реально душно. Так, всего лишь скромное наблюдение над логикой работы свопления реально существующих ОС в реальных условиях их использования.
Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.Я не знаю, какими дистрибутивами вы пользуетесь, но ситуация, которую вы описываете, как раз характерна для неправильной работы механизма распределения памяти. Выкинуть в своп - всегда правильное решение для least recently used данных, особенно на сервере. При недостатке памяти первым делом он покиляет дисковые кэши, а уж потом начнет выгружать в своп страницы.
Если вы дергаете постоянно приложения, переключаясь между ними, очевидно, что грамотный менеджер памяти не будет выкидывать их в своп, возможно, именно про это отличие от windows вы говорите. Но понятно, что выкинуть страницы софта, отожравшего три дня назад 300 Мб памяти и не обращавшегося к ним, для ускорения интенсивного обмена с диском той же самой MySQL или для потребностей другого ресурсоемкого приложения - прямая обязанность диспетчера памяти.
Также учитывайте механизм выделения памяти приложению в Linux - приложению по факту выделения количество памяти не гарантируется, это не физические страницы, а страницы выдаются по попытке доступа к ним. overcommit + swapiness, рекомендую обратить внимание. Чтобы в один прекрасный день не обнаружить сервис, который выжрал 8 Гб якобы имеющейся в системе без свопа памяти, которая на самом-то деле уже распределена ;)
>Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов
>памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.А г-ди, исходники ядра.. google://vm.swappiness vm.vfs_cache_pressure, насчет oom killer с компанией — vm.overcommit_memory vm.oom_kill_allocating_task vm.overcommit_ratio
Врядли вам нужно больше.
vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу данных при имеющейся свободной памяти как относятся?
>vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу
>данных при имеющейся свободной памяти как относятся?vm.swappiness вроде бы непосредственно, а остальные к oom же
> по моим наблюдениям линух юзает своп лишь когда реально припираетПо умолчанию это не так. Но можно настроить (значение в /proc/sys/vm/swappiness).
А RT-приложения все равно используют memlock, если пользователю разрешено.
>По умолчанию это не так.В каких ядрах, ос и прочая? В ванилле какойнить? А то попавшиеся под руку "десктопные" линухи вели себя именно описанным мной образом - своп обычно пустой пока не начнет натурально прижимать :).Да и на серверных что-то не видел отлива в своп пока душняк не наступил. Что я делаю не так? oO
Похоже, что ты вообще мало имел дел с линуксом. Только троллить горазд на опеннете.
>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)Риал тайм жаба не собирает мусор когда не надо
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.
Свап можно выключить, что нормально для встраиваемых систем. А как обстоят дела с десктопными решениями?
И вообще, 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);
нет, не согласен в книги FreeBSD. Архитектура и реализация. Невил-нил Д. В., Маккузик М. К
имеено проблема была со свапом, поэтому FreeBSD не может работать как real-time система + ОЧЕНЬ БОЛЬШОЙ ВОПРОС TCP/IP как будете прогнозировать точное время выполения задачи?????????????????????????? так что реализация, только для локальной хоста, не более (причем без сваппа) и скорее всего без некоторых системных процессов, например будет потеря кол-ва времени (тиков) для ругих процессов (системынх и пользовательсикх) так как весь cpu будет отдан под задачу real-time, что скореевсего скажется на целостности системы,из-за невозможности отдать время системному процессу. Хотя согласен, для систем "мягкого реального времени" планировщик пойдет, для жесткого нет - ответ системы не детерминирован.
>нет, не согласен в книги 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 мульёнов периодов полураспада какого-то там изпопа Цезия?
Тут доказали, что скорость света не постоянна, а вы про время...
>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не новом шаге, а в том, что разгребают старые ошибки, когда ядро изначально не было реалтайм. Уменьшение патча на 350 Кб - это, безусловно, прорыв!
>>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!
>
>Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не
> новом шаге, а в том, что разгребают старые ошибки, когда
>ядро изначально не было реалтайм. Уменьшение патча на 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 говоря по-нашему :)
Ибо что будя завтра, не знает даже "то, чаво не может быть".