| 1.1, Zenitur (?), 16:58, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 И это здорово!
одно из применений RT-ядра - студии звукозаписи. Во всех ориентированных на это дистрибутивах только RT-ядро.
| | |
| |
| 2.5, anonimus (?), 17:23, 10/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, но только оно не всегда спасает, когда дело упирается в планировщик ввода/вывода - все со звуком начинает кавкать, икать и заикаться...
Попробуйте в Ardour пару десятков треков с эффектами покрутить...
Надеюсь, что эти нововведения хоть как-то поправят положение дел в лучшую сторону...
Хотя с планировщиком тоже что-то нужно делать, уже с 24-го RT ядра тянется это все дело...
| | |
| |
| 3.17, devl547 (?), 20:12, 10/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>планировщик ввода/вывода
BFQ/NOOP/SIO - попробуйте, может что поможет.
| | |
| |
| 4.18, anonimus (?), 20:16, 10/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>планировщик ввода/вывода
>
>BFQ/NOOP/SIO - попробуйте, может что поможет.
Вы наверное хотели сказать cfq anticipatory deadline noop
пробовал все - проблема не разрешается...
| | |
|
| 3.26, Basiley (ok), 03:26, 11/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
попробуйте поиграться с ionice.
к сожаленю текущая версия reniced - рулит только планирвоащиками CPU(без IO).
мб выйдет аналог.
| | |
|
|
| 1.2, Аноним (2), 16:58, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Томас Глейкснер создал серию патчей, которые Линус включил в ядро 2.6.33." - как же это кажется приятным.
тестировал летом, помнится что были проблемы в 2.6.31 с виртуалбоксом - интересно что получится..
| | |
| 1.3, Аноним (3), 17:16, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
 >одно из применений RT-ядра - студии звукозаписи.
Зачем оно этим студиям такое реалтаймовое ядро понадобилось, под которое музыкального софта то и нет нормального.
| | |
| |
| 2.7, аноним (?), 17:44, 10/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> под которое музыкального софта то и нет нормального
Вы шутите?
| | |
|
| 1.4, Аноним (-), 17:19, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Често не понимаю суть новости. Так какими-же должны быть спинлоки в режиме реального времени? Те что засыпают уже вряд-ли можно назвать спинлоками. Это скорее уже семафоры.
| | |
| 1.11, друг XoRe (?), 18:41, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
что-то я не совсем пойму, помогите: ядро Linux работает со свап пространством, о какой реал тайм может идти речь? или это про встроенные системы? допуская что в "мягком" виде,но не в "жестком" еще можно прогнозировать выполнение задачи на время загруки выгрузки(время) swap контекста.
| | |
| |
| 2.13, uZver (??), 19:09, 10/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
а если не допускать работы со свапом? заблокать его к примеру? ядро без RT-патчей все равно не будет реал-таймовым...
| | |
| 2.16, User294 (ok), 19:48, 10/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Я что-то не вдупляю: что мешает не пользоваться свопом? А так - по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну, будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)
ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
| | |
| |
| 3.19, KdF (??), 20:44, 10/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Я что-то не вдупляю: что мешает не пользоваться свопом? А так -
>по моим наблюдениям линух юзает своп лишь когда реально припирает. Ну,
>будет вам OOM kill вместо тормозов от свопа. Как, полегчало? :)
>
>
>ЗЫ павлин вон написал более цивильный пример борьбы с пакостями.
>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
Ну вообще-то линукс как раз может юзать своп, хотя еще очень много свободной памяти. Всякое lru туда скидывает и радуется, освобождая память. Другое дело, что если не будет свопа, он просто не будет этого делать.
| | |
| |
| 4.30, User294 (ok), 10:56, 11/02/2010 [^] [^^] [^^^] [ответить] | –1 +/– | Простите, а вы это в теории проверяли или на практике По шагам 1 Берем маши... большой текст свёрнут, показать | | |
| |
| 5.32, KdF (??), 02:48, 12/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.
Я не знаю, какими дистрибутивами вы пользуетесь, но ситуация, которую вы описываете, как раз характерна для неправильной работы механизма распределения памяти. Выкинуть в своп - всегда правильное решение для least recently used данных, особенно на сервере. При недостатке памяти первым делом он покиляет дисковые кэши, а уж потом начнет выгружать в своп страницы.
Если вы дергаете постоянно приложения, переключаясь между ними, очевидно, что грамотный менеджер памяти не будет выкидывать их в своп, возможно, именно про это отличие от windows вы говорите. Но понятно, что выкинуть страницы софта, отожравшего три дня назад 300 Мб памяти и не обращавшегося к ним, для ускорения интенсивного обмена с диском той же самой MySQL или для потребностей другого ресурсоемкого приложения - прямая обязанность диспетчера памяти.
Также учитывайте механизм выделения памяти приложению в Linux - приложению по факту выделения количество памяти не гарантируется, это не физические страницы, а страницы выдаются по попытке доступа к ним. overcommit + swapiness, рекомендую обратить внимание. Чтобы в один прекрасный день не обнаружить сервис, который выжрал 8 Гб якобы имеющейся в системе без свопа памяти, которая на самом-то деле уже распределена ;)
| | |
| |
| 6.34, anonymous (??), 15:46, 12/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Честно говоря, критериев, приводящих к выбросу в своп при конкретных значениях объемов
>памяти, дисковых буферов, и других параметров, я не знаю, в исходниках ядра бываю редко.
А г-ди, исходники ядра.. google://vm.swappiness vm.vfs_cache_pressure, насчет oom killer с компанией — vm.overcommit_memory vm.oom_kill_allocating_task vm.overcommit_ratio
Врядли вам нужно больше.
| | |
| |
| 7.35, KdF (??), 15:20, 14/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
vfs_cache_pressure не видел, посмотрю, про остальные в курсе, но они к свопу данных при имеющейся свободной памяти как относятся?
| | |
|
|
|
|
| 3.20, Tav (ok), 21:39, 10/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> по моим наблюдениям линух юзает своп лишь когда реально припирает
По умолчанию это не так. Но можно настроить (значение в /proc/sys/vm/swappiness).
А RT-приложения все равно используют memlock, если пользователю разрешено.
| | |
| |
| 4.31, User294 (ok), 10:58, 11/02/2010 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>По умолчанию это не так.
В каких ядрах, ос и прочая? В ванилле какойнить? А то попавшиеся под руку "десктопные" линухи вели себя именно описанным мной образом - своп обычно пустой пока не начнет натурально прижимать :).Да и на серверных что-то не видел отлива в своп пока душняк не наступил. Что я делаю не так? oO
| | |
| |
| 5.33, aZ (ok), 03:33, 12/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Похоже, что ты вообще мало имел дел с линуксом. Только троллить горазд на опеннете.
| | |
|
|
| 3.21, anonymous vulgaris (?), 21:40, 10/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>ЗЗЫ эй, поклонники гарбаж коллекторов, изобразите чтонить подобное? :)
Риал тайм жаба не собирает мусор когда не надо
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.
| | |
|
|
| 1.12, Nick (??), 19:00, 10/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Свап можно выключить, что нормально для встраиваемых систем. А как обстоят дела с десктопными решениями?
| | |
| |
| 2.14, pavlinux (ok), 19:10, 10/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
И вообще, 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);
| | |
| |
| 3.22, друг XoRe (?), 22:55, 10/02/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
нет, не согласен в книги FreeBSD. Архитектура и реализация. Невил-нил Д. В., Маккузик М. К
имеено проблема была со свапом, поэтому FreeBSD не может работать как real-time система + ОЧЕНЬ БОЛЬШОЙ ВОПРОС TCP/IP как будете прогнозировать точное время выполения задачи?????????????????????????? так что реализация, только для локальной хоста, не более (причем без сваппа) и скорее всего без некоторых системных процессов, например будет потеря кол-ва времени (тиков) для ругих процессов (системынх и пользовательсикх) так как весь cpu будет отдан под задачу real-time, что скореевсего скажется на целостности системы,из-за невозможности отдать время системному процессу. Хотя согласен, для систем "мягкого реального времени" планировщик пойдет, для жесткого нет - ответ системы не детерминирован.
| | |
| |
| 4.28, pavlinux (ok), 03:43, 11/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>нет, не согласен в книги 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 мульёнов периодов полураспада какого-то там изпопа Цезия?
Тут доказали, что скорость света не постоянна, а вы про время...
| | |
|
|
|
| 1.23, аноним (?), 02:09, 11/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!
Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не новом шаге, а в том, что разгребают старые ошибки, когда ядро изначально не было реалтайм. Уменьшение патча на 350 Кб - это, безусловно, прорыв!
| | |
| |
| 2.25, pavlinux (ok), 03:06, 11/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>еще одна важная веха на пути к полной интеграции «Реального времени» в основную ветку ядра!
>
>Автору новости - поменьше пафоса, вы не на первомайской демонстрации. Суть не
> новом шаге, а в том, что разгребают старые ошибки, когда
>ядро изначально не было реалтайм. Уменьшение патча на 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 говоря по-нашему :)
Ибо что будя завтра, не знает даже "то, чаво не может быть".
| | |
|
|
