URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 59486
[ Назад ]

Исходное сообщение
"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."

Отправлено opennews , 01-Окт-09 11:13 
Немецкая компания Pengutronix объявила (http://groups.google.com/group/fa.linux.kernel/msg/522c67f96...) о начале поддержки пакетов для Debian GNU/Linux с модифицированным для выполнения задач реального времени Linux ядром.  Пакеты основаны на "Realtime-Preempt (http://rt.wiki.kernel.org/)" (PREEMPT_RT или "-rt") патчах с реализацией жёсткого режима реального времени. Доступны realtime-сборки ядер 2.6.29 (стабильная PREEMPT_RT ветка) и 2.6.31 (экспериментальная PREEMPT_RT ветка) для веток Debian Lenny, Sid и Squeeze в сборках для архитектур 486, 686, 686-bigmen и amd64.

URL: http://groups.google.com/group/fa.linux.kernel/msg/522c67f96...
Новость: http://www.opennet.me/opennews/art.shtml?num=23668


Содержание

Сообщения в этом обсуждении
"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 01-Окт-09 11:13 
а какое из этих ядер подойдет на убунту 9.04 32 бит?

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено _ , 01-Окт-09 11:36 
посмотри в синаптике. там есть рт патчи

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено 82500 , 01-Окт-09 11:20 
А какой вообще от них реальный толк?

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Feadot , 01-Окт-09 11:26 
От реального времени?

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено ShPioN , 01-Окт-09 11:27 
при сильных нагрузках отклик системы будет быстрее. например у меня на обычном ядре при интенсивных операциях с дисками все остальное буквально еле шевелется, даже мышка подрагивает...

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено svn , 01-Окт-09 12:19 
>например у меня на обычном ядре при интенсивных операциях с дисками все остальное буквально еле шевелется, даже мышка подрагивает...

Тебе и реалтайм не поможет )) У тебя не настроена vm (свапы/кеши пропорции итп) и возможно не работает dma.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 12:53 
>У тебя не настроена vm (свапы/кеши пропорции итп)

У меня вообще нет свопа. На 6 гиг я считаю ни нужен.
%free                                                                                                    total       used       free     shared    buffers     cached
Mem:       6001732    4972148    1029584          0       1592    2921688
-/+ buffers/cache:    2048868    3952864
Swap:            0          0          0

> и возможно не работает dma.

Процессор при этом не занят. Если бы dma не работал (хотя для 1Т Sata жесткого я себе плохо представляю) проц бы загружался по полной (во всяком случае один из трех).



"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено svn , 01-Окт-09 16:11 
>У меня вообще нет свопа.

У тебя нет выгрузки на диск анонимных страниц. А readonly секции кода программ, и прочие отображаемые в память файлы отлично вытесняются на диск для освобождения кеша. И при особенно не удачной конфигурации, ядро их гоняет туда и обратно непрерывно.

Чтобы считать ПРАВИЛЬНО, надо знать как работает vm система в linux, тогда и настроишь коэфициенты /proc/sys/vm правильно, и свап не будешь выключать.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено casm , 01-Окт-09 22:40 
Можно поподробнее? Меня этот вопрос очень интересует.
На рабочей машине 2 Гб ОЗУ, процессор core2duo, два жестких диска, на каждом диске по 1 Гб-ому своп разделу в начале диска. В fstab приоритеты swap-ов одинаковы, swapon -s это подтверждает.
Запускаю две виртуальные машины, под каждую выделено 512 МБ памяти.
Если запустить только одну виртуальную - то все летает (своп почти не используется), как только запускаю вторую - система, что на физической машине, начинает сильно тормозить, система начинает сбрасывать страницы в своп, хотя в сумме используется около 1,5 ГБ ОЗУ.
Экспериментально заметил, что если использует менее 50 % от объема ОЗУ, то все летает, как только больше начинаются тормоза.
При этом Cached память занимает почти 50%.
Пробовал ставить vm.swappiness = 5, vm.vfs_cache_pressure = 5000 - не помогает,
Попробовал выставить dirty_writeback_centisecs=100, dirty_expire_centisecs=100, dirty_background_ratio=10, dirty_ratio=10 тоже не лучше.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 22:52 
>[оверквотинг удален]
>Запускаю две виртуальные машины, под каждую выделено 512 МБ памяти.
>Если запустить только одну виртуальную - то все летает (своп почти не
>используется), как только запускаю вторую - система, что на физической машине,
>начинает сильно тормозить, система начинает сбрасывать страницы в своп, хотя в
>сумме используется около 1,5 ГБ ОЗУ.
>Экспериментально заметил, что если использует менее 50 % от объема ОЗУ, то
>все летает, как только больше начинаются тормоза.
>При этом Cached память занимает почти 50%.
>Пробовал ставить vm.swappiness = 5, vm.vfs_cache_pressure = 5000 - не помогает,
>Попробовал выставить dirty_writeback_centisecs=100, dirty_expire_centisecs=100, dirty_background_ratio=10, dirty_ratio=10 тоже не лучше.

А почему бы кешу не занимать и больше если указана опция vm.vfs_cache_pressure = 5000 - что приблизительно значит: принудительно сбрасывать кеш если он занимает больше 5000% от текущего объема ОЗУ... При такой настройке кеш никогда не сброситься... Или я ошибаюсь?

Для начала может быть попробовать опции по умолчанию? - Что они покажут?


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено casm , 02-Окт-09 20:12 
>Для начала может быть попробовать опции по умолчанию? - Что они покажут?

По-умолчанию такая же ситуация - при загрузке памяти более 50% производительность падает.
Забыл дописать, что ставил vm.vfs_cache_pressure = 10 результат ничуть не лучше.
Описание vfs_cache_pressure с proc.txt из документации к ядру для меня довольно смутное.
> Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches.  
> Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes.

В инете в основным ссылается на комментарий к патчу:
- at vfs_cache_pressure=0 we don't shrink dcache and icache at all.
- at vfs_cache_pressure=100 there is no change in behaviour.
- at vfs_cache_pressure > 100 we reclaim dentries and inodes harder.

Как я понял (если не так поправьте) увеличение параметра способствует сокращению кешей (dentries and inodes).
Про то, что оно указывается в процентах от ОЗУ нигде не встречал.
Думаю если уменьшить тягу к увеличению кеша, то все уместиться в ОЗУ, и не будет так медлить при работе. Вот и интересуюсь как это сделать.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 02-Окт-09 20:26 
>>Для начала может быть попробовать опции по умолчанию? - Что они покажут?
>
>По-умолчанию такая же ситуация - при загрузке памяти более 50% производительность падает.
>

У меня подобная ситуация - но с одним "НО" - у меня это не зависит от текущего объема занимаемого ОЗУ - все тормоза и рост iowait начинаются строго с того момента как начинает использоваться активно сброс/чтение swap... Иногда даже невозможно дальше работать - откликов нет ни на клавиатуру ни на мышу...

На счет vfs_cache_pressure утверждать ничего не буду - так как попадались статьи, за разные годы их написания, и в каждой статье были разные значения этой опции; и в том числе тоже попадалось о патче позволяющем увеличивать значение этого параметра больше 100%...
Просто похоже что с учетом развития ядра эта опция принимала разную смысловую нагрузку... Пусть гуру меня поправят, если я ошибаюсь...


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено casm , 02-Окт-09 21:20 
> все тормоза и рост iowait начинаются строго с того момента как начинает использоваться
> активно сброс/чтение swap

У меня аналогично, и я думаю, что сброс и начинается от того, что в этот момент недостаточно свободной памяти, по той причине, что зарезервировано много cached memory.

Еще хочу обратить внимание, что если приложениями используется 700-800 Мб, то и cached не более 400 МБ. Если же запустить тяжёлые процессы (в сумме требующие > 1,5 Гб), то и cached memory увеличивается до 1,0-1,3 ГБ и вот тут начинается активное использование swap.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 02-Окт-09 22:12 
>> все тормоза и рост iowait начинаются строго с того момента как начинает использоваться
>> активно сброс/чтение swap
>
>У меня аналогично, и я думаю, что сброс и начинается от того,
>что в этот момент недостаточно свободной памяти, по той причине, что
>зарезервировано много cached memory.
>
>Еще хочу обратить внимание, что если приложениями используется 700-800 Мб, то и cached не более 400 МБ. Если же запустить тяжёлые процессы (в сумме требующие > 1,5 Гб), то и cached memory увеличивается до 1,0-1,3 ГБ и вот тут начинается активное использование swap.

А если попробовать с такими значениями:
vm.overcommit_memory = 2
vm.vfs_cache_pressure=35
А все остальное по умолчанию...


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 02-Окт-09 22:52 
Не знаю...
Крутил вертел разные значения - при одних одни глюки при других - другие...(то перестает выделять память - то выдает, но тупит страшнее всего)
Вернул значения по умолчанию - хоть и глюков стало меньше, но тормоза еще те, когда доходит до свопа...

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 02-Окт-09 20:34 
>[оверквотинг удален]
>- at vfs_cache_pressure=100 there is no change in behaviour.
>- at vfs_cache_pressure > 100 we reclaim dentries and inodes harder.
>
>Как я понял (если не так поправьте) увеличение параметра способствует сокращению кешей
>(dentries and inodes).
>Про то, что оно указывается в процентах от ОЗУ нигде не встречал.
>
>Думаю если уменьшить тягу к увеличению кеша, то все уместиться в ОЗУ,
>и не будет так медлить при работе. Вот и интересуюсь как
>это сделать.

Вот кстати те участки кода где задействовано vfs_cache_pressure:
../fs/inode.c

/*
* shrink_icache_memory() will attempt to reclaim some unused inodes.  Here,
* "unused" means that no dentries are referring to the inodes: the files are
* not open and the dcache references to those inodes have already been
* reclaimed.
*
* This function is passed the number of inodes to scan, and it returns the
* total number of remaining possibly-reclaimable inodes.
*/
static int shrink_icache_memory(int nr, gfp_t gfp_mask)
{
        if (nr) {
                /*
                 * Nasty deadlock avoidance.  We may hold various FS locks,
                 * and we don't want to recurse into the FS that called us
                 * in clear_inode() and friends..
                 */
                if (!(gfp_mask & __GFP_FS))
                        return -1;
                prune_icache(nr);
        }
        return (inodes_stat.nr_unused / 100) * sysctl_vfs_cache_pressure;
}

../fs/dcache.c

/*
* Scan `nr' dentries and return the number which remain.
*
* We need to avoid reentering the filesystem if the caller is performing a
* GFP_NOFS allocation attempt.  One example deadlock is:
*
* ext2_new_block->getblk->GFP->shrink_dcache_memory->prune_dcache->
* prune_one_dentry->dput->dentry_iput->iput->inode->i_sb->s_op->put_inode->
* ext2_discard_prealloc->ext2_free_blocks->lock_super->DEADLOCK.
*
* In this case we return -1 to tell the caller that we baled.
*/
static int shrink_dcache_memory(int nr, gfp_t gfp_mask)
{
        if (nr) {
                if (!(gfp_mask & __GFP_FS))
                        return -1;
                prune_dcache(nr);
        }
        return (dentry_stat.nr_unused / 100) * sysctl_vfs_cache_pressure;
}

../fs/mbcache.c

/*
* mb_cache_shrink_fn()  memory pressure callback
*
* This function is called by the kernel memory management when memory
* gets low.
*
* @nr_to_scan: Number of objects to scan
* @gfp_mask: (ignored)
*
* Returns the number of objects which are present in the cache.
*/
static int
mb_cache_shrink_fn(int nr_to_scan, gfp_t gfp_mask)
{
        LIST_HEAD(free_list);
        struct list_head *l, *ltmp;
        int count = 0;

        spin_lock(&mb_cache_spinlock);
        list_for_each(l, &mb_cache_list) {
                struct mb_cache *cache =
                        list_entry(l, struct mb_cache, c_cache_list);
                mb_debug("cache %s (%d)", cache->c_name,
                          atomic_read(&cache->c_entry_count));
                count += atomic_read(&cache->c_entry_count);
        }
        mb_debug("trying to free %d entries", nr_to_scan);
        if (nr_to_scan == 0) {
                spin_unlock(&mb_cache_spinlock);
                goto out;
        }
        while (nr_to_scan-- && !list_empty(&mb_cache_lru_list)) {
                struct mb_cache_entry *ce =
                        list_entry(mb_cache_lru_list.next,
                                   struct mb_cache_entry, e_lru_list);
                list_move_tail(&ce->e_lru_list, &free_list);
                __mb_cache_entry_unhash(ce);
        }
        spin_unlock(&mb_cache_spinlock);
        list_for_each_safe(l, ltmp, &free_list) {
                __mb_cache_entry_forget(list_entry(l, struct mb_cache_entry,
                                                   e_lru_list), gfp_mask);
        }
out:
        return (count / 100) * sysctl_vfs_cache_pressure;
}


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено xGa , 01-Окт-09 11:36 
робототехника, производственные процессы, возможно даже САПР.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 01-Окт-09 11:49 
> возможно даже САПР.

Зачем для САПР режим жесткого реального времени?



"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 12:13 
А как вы считаете стоит ли на него перейти на десктопе? Может быть там менеджер задач более приспособлен для пользователя?
Или все-таки это будет бесполезно?
Мне главное, чтоб отзывчивость была выше, и чтобы фильмы не тормозили, когда у меня в КДЕ обои меняются.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Шурек Табуреткин , 01-Окт-09 12:21 
Апгрейд тебе в помощь, а рт-ядро не даст тебе желаемого результата.
Попробуй 31-ю ветку ядра кстати, говорят, отзывчивость там лучше намного.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Nexor , 01-Окт-09 12:25 
Такие ядра нужны только в критичных областях. Ну вот пример атомная станция: нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для этого нужно гарантированное время отклика системы. Как только пришёл ахтунг - система отреагирует и не будет ждать пока какой то процесс отвиснет.

На десктопах оно не нужно


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 12:27 
Ну у меня конечно не атомная станция, но я тоже не хочу чтобы у меня компьютер тормозил. Это при том что 3 процессора и 6 гиг оперативы.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Vertigo , 01-Окт-09 12:30 
И что, неужто тормозит? ))

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 12:35 
Тормозит :(
http://linuxforum.ru/index.php?showtopic=100776
Что сделать даже и не знаю.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 12:42 
>И что, неужто тормозит? ))

И если из локалки много фильмов одновременно качаю ослом - тоже бывает, что мышка дергаться начинает и отрисовка замедляется существенно.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено svn , 01-Окт-09 16:15 
>И если из локалки много фильмов одновременно качаю ослом - тоже бывает,
>что мышка дергаться начинает и отрисовка замедляется существенно.

система должна быть сбалансированная.
3 процессора, 6 гигов, а было бы 4 диска да 10 или 5 рейд, и работало бы всё намного веселее


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено crypt , 01-Окт-09 19:08 
>>И если из локалки много фильмов одновременно качаю ослом - тоже бывает,
>>что мышка дергаться начинает и отрисовка замедляется существенно.
>
>система должна быть сбалансированная.
>3 процессора, 6 гигов, а было бы 4 диска да 10 или
>5 рейд, и работало бы всё намного веселее

сбалансированная - да. 1+0 рейд - да. а вот 5 - нет, это компромиссное решение и тормоз. и там выше насчет vm ты тоже слишком категоричен.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено crypt , 01-Окт-09 19:05 
hdparm -t твой диск
выложи сюда, тогда будет яснее.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено ShPioN , 01-Окт-09 19:15 
>hdparm -t твой диск
>выложи сюда, тогда будет яснее.

у меня тоже самое, вот hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads:  246 MB in  3.00 seconds =  81.94 MB/sec

а система бывает загибается уже при 40-45МБ/с на файловой системе ехт3 или рейзер.


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено maximnik0 , 01-Окт-09 22:15 
>>hdparm -t твой диск
>>выложи сюда, тогда будет яснее.
>
>у меня тоже самое, вот hdparm -t /dev/sda
>/dev/sda:
> Timing buffered disk reads:  246 MB in  3.00 seconds
>=  81.94 MB/sec
>
>а система бывает загибается уже при 40-45МБ/с на файловой системе ехт3 или
>рейзер.

Насколько я понял ядро 64 разрядное ?
А  кодеки тоже оптимизированы под 64 режим  ?


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено ShPioN , 01-Окт-09 22:20 
>[оверквотинг удален]
>>у меня тоже самое, вот hdparm -t /dev/sda
>>/dev/sda:
>> Timing buffered disk reads:  246 MB in  3.00 seconds
>>=  81.94 MB/sec
>>
>>а система бывает загибается уже при 40-45МБ/с на файловой системе ехт3 или
>>рейзер.
>
>Насколько я понял ядро 64 разрядное ?
>А  кодеки тоже оптимизированы под 64 режим  ?

ядро 32 битное :)


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено koblin , 01-Окт-09 13:27 
попробуйте 31-е ядро с браинфак шедулером. Многие пишут, что флеш например на полный экран начинает работать без тормозов и загрузка ядер равномернее.

ps правда у меня в убунте 9.10 флеш и без патчей нормально проигрывается (i915)


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 13:33 
>попробуйте 31-е ядро с браинфак шедулером. Многие пишут, что флеш например на
>полный экран начинает работать без тормозов и загрузка ядер равномернее.
>
>ps правда у меня в убунте 9.10 флеш и без патчей нормально
>проигрывается (i915)

Да - но только обращаю ваше внимание что это, на сколько я знаю, не относится к RT ядру...
Патчи браинфак на RT ядро не подходят...


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 13:12 
>Такие ядра нужны только в критичных областях. Ну вот пример атомная станция:
>нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для
>этого нужно гарантированное время отклика системы. Как только пришёл ахтунг -
>система отреагирует и не будет ждать пока какой то процесс отвиснет.
>
>
>На десктопах оно не нужно

Еще как нужно!


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено zeo , 01-Окт-09 13:53 
Я попробовал поставить. Загрузилось, но вот модуль Nvidia не смог скомпилироваться. Брал последние тестовые дрова.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 13:57 
>Я попробовал поставить. Загрузилось, но вот модуль Nvidia не смог скомпилироваться. Брал
>последние тестовые дрова.

nv-2.6.31-rt-190-36.patch:

diff -Naur NVIDIA-Linux-x86_64-190.32-pkg2/usr/src/nv/nv-linux.h NVIDIA-Linux-x86_64-190.32/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-x86_64-190.32-pkg2/usr/src/nv/nv-linux.h    2009-09-02 11:54:49.000000000 +0100
+++ NVIDIA-Linux-x86_64-190.32/usr/src/nv/nv-linux.h    2009-09-17 21:05:45.000000000 +0100
@@ -742,20 +742,28 @@
#define nv_down(lock)                   down(&lock)
#define nv_up(lock)                     up(&lock)

+#if defined(CONFIG_PREEMPT_RT) && !defined(init_MUTEX)
+#  define nv_spin_lock_init(lock)              atomic_spin_lock_init(lock)
+#  define nv_spin_lock_irqsave(lock, irq)      atomic_spin_lock_irqsave(lock, irq)
+#  define nv_spin_unlock_irqrestore(lock, irq) atomic_spin_unlock_irqrestore(lock, irq)
+#else
+#  define nv_spin_lock_init(lock)              spin_lock_init(lock)
+#  define nv_spin_lock_irqsave(lock, irq)      spin_lock_irqsave(lock, irq)
+#  define nv_spin_unlock_irqrestore(lock, irq) spin_unlock_irqrestore(lock, irq)
+#endif
+
#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) init_MUTEX(mutex)
+#  if defined(init_MUTEX)
+#    define nv_spinlock_t raw_spinlock_t
+#  else
+#    define nv_spinlock_t atomic_spinlock_t
+#  endif
#else
-#if !defined(__SEMAPHORE_INITIALIZER) && defined(__COMPAT_SEMAPHORE_INITIALIZER)
-#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
-#endif
-#define NV_INIT_MUTEX(mutex)                       \
-    {                                              \
-        struct semaphore __mutex =                 \
-            __SEMAPHORE_INITIALIZER(*(mutex), 1);  \
-        *(mutex) = __mutex;                        \
-    }
+#  define nv_spinlock_t   spinlock_t
#endif

+#define NV_INIT_MUTEX(mutex) sema_init(mutex, 1)
+
#if defined (KERNEL_2_4)
#  define NV_IS_SUSER()                 suser()
#  define NV_PCI_DEVICE_NAME(dev)       ((dev)->name)
diff -Naur NVIDIA-Linux-x86_64-190.32-pkg2/usr/src/nv/os-interface.c NVIDIA-Linux-x86_64-190.32/usr/src/nv/os-interface.c
--- NVIDIA-Linux-x86_64-190.32-pkg2/usr/src/nv/os-interface.c    2009-09-02 11:54:48.000000000 +0100
+++ NVIDIA-Linux-x86_64-190.32/usr/src/nv/os-interface.c    2009-09-17 21:05:45.000000000 +0100
@@ -108,11 +108,7 @@
{
     nv_stack_t        *sp;
     struct completion  completion;
-#if defined(CONFIG_PREEMPT_RT)
-    raw_spinlock_t     lock;
-#else
-    spinlock_t         lock;
-#endif
+    nv_spinlock_t      lock;
     S032               count;
} os_sema_t;

@@ -148,7 +144,7 @@
     os_sema = (os_sema_t *)*ppSema;
     os_sema->sp = sp;
     init_completion(&os_sema->completion);
-    spin_lock_init(&os_sema->lock);
+    nv_spin_lock_init(&os_sema->lock);
     os_sema->count = 1;

     if (nv_os_smp_barrier_init())
@@ -199,18 +195,18 @@
     os_sema_t *os_sema = (os_sema_t *)pSema;
     unsigned long old_irq;

-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count <= 0)
     {
         os_sema->count--;
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         wait_for_completion(&os_sema->completion);
     }
     else
     {
         os_sema->count--;
         rm_disable_interrupts(os_sema->sp);
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
     }

     return RM_OK;
@@ -233,17 +229,17 @@
     os_sema_t *os_sema = (os_sema_t *)pSema;
     unsigned long old_irq;

-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count <= 0)
     {
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         return RM_ERROR;
     }
     else
     {
         os_sema->count--;
         rm_disable_interrupts(os_sema->sp);
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         return RM_OK;
     }

@@ -267,7 +263,7 @@
     unsigned long old_irq;
     BOOL doWakeup;

-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count < 0)
     {
         doWakeup = TRUE;
@@ -278,7 +274,7 @@
         rm_enable_interrupts(os_sema->sp);
     }
     os_sema->count++;
-    spin_unlock_irqrestore(&os_sema->lock, old_irq);
+    nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);

     if (doWakeup)
         complete(&os_sema->completion);
@@ -1383,7 +1379,7 @@
     unsigned long oldIrql;

     os_sema = (os_sema_t *) pSema;
-    spin_lock_irqsave(&os_sema->lock, oldIrql);
+    nv_spin_lock_irqsave(&os_sema->lock, oldIrql);

     return oldIrql;
}
@@ -1394,7 +1390,7 @@
     unsigned long old_irq = (unsigned long) oldIrql;

     os_sema = (os_sema_t *) pSema;
-    spin_unlock_irqrestore(&os_sema->lock, old_irq);
+    nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
}

RM_STATUS NV_API_CALL os_get_address_space_info(


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено pavlinux , 01-Окт-09 21:24 
Окуел..., там всего две строки поменять

http://www.nvnews.net/vbulletin/showthread.php?t=139143

diff -ur 190.32/usr/src/nv/nv-linux.h 190.32-rt/usr/src/nv/nv-linux.h
--- nv-linux.h    2009-09-08 23:57:13.000000000 +0400
+++ nv-linux.h    2009-09-23 22:15:05.889398178 +0400
@@ -743,7 +743,7 @@
#define nv_up(lock)                     up(&lock)

#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) init_MUTEX(mutex)
+#define NV_INIT_MUTEX(mutex) semaphore_init(mutex)
#else
#if !defined(__SEMAPHORE_INITIALIZER) && defined(__COMPAT_SEMAPHORE_INITIALIZER)
#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
diff -ur 190.32/usr/src/nv/os-interface.c 190.32-rt/usr/src/nv/os-interface.c
--- os-interface.c    2009-09-08 23:57:13.000000000 +0400
+++ os-interface.c    2009-09-23 22:21:27.826648129 +0400
@@ -108,11 +108,7 @@
{
     nv_stack_t        *sp;
     struct completion  completion;
-#if defined(CONFIG_PREEMPT_RT)
-    raw_spinlock_t     lock;
-#else
     spinlock_t         lock;
-#endif
     S032               count;
} os_sema_t;


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 21:36 
>[оверквотинг удален]
>     struct completion  completion;
>-#if defined(CONFIG_PREEMPT_RT)
>-    raw_spinlock_t     lock;
>-#else
>     spinlock_t      
>  lock;
>-#endif
>     S032      
>        count;
> } os_sema_t;

И Шо я вас таки не понял....
К чему такая фамильярность?
Патч не мой!
Говорю о том на чем система стабильно работать начала на том указанном ядре!
За что купил - за то и продал!

К тому же не тяжело попробовать тот и другой вариант! - Руки не отсохнут...
Убийственного в этом ничего нет...


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено pavlinux , 01-Окт-09 21:45 
>[оверквотинг удален]
>>-#else
>>     spinlock_t      
>>  lock;
>>-#endif
>>     S032      
>>        count;
>> } os_sema_t;
>
>И Шо я вас таки не понял....
>К чему такая фамильярность?

Ну шо ты...,  я ж любя ж :)


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 23-Окт-09 12:41 
>Я попробовал поставить. Загрузилось, но вот модуль Nvidia не смог скомпилироваться. Брал
>последние тестовые дрова.

Новость!
ftp://download.nvidia.com/XFree86/Linux-x86_64/190.42/
Вот эти дрова собираются под RT ядром без каких-либо шаманств :)


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Онаним , 01-Окт-09 17:49 
>Такие ядра нужны только в критичных областях. Ну вот пример атомная станция:
>нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для
>этого нужно гарантированное время отклика системы. Как только пришёл ахтунг -
>система отреагирует и не будет ждать пока какой то процесс отвиснет.

Хозяева атомной станции вполне могут раскошелиться на QNX. Он специально создавался для таких целей, в отличие от поделок на основе линуха.



"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 01-Окт-09 19:47 
А вот, кто ж его знает. Сверкомпактные необслуживаемые атомные станции "заснул в подвал и дом на сорок лет обеспечен дешевым электричеством" как бы уже пытаются делать, например http://www.nextenergynews.com/news1/next-energy-news-toshiba...

Причем основная ставка именно на дешевизну по сравнению с электричеством по линии. То есть ставим потому, что экономим, типа! А там где экономим - линукс вместо коммерческих ОС сам собой вылезать начинает :) А тут, глядишь, и база готова, ставишь Debian "Atomic Edition" и вперед!


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Fantomas , 01-Окт-09 20:49 
>Сверкомпактные необслуживаемые атомные станции "заснул в подвал и дом на сорок лет >обеспечен дешевым электричеством" как бы уже пытаются делать, например >http://www.nextenergynews.com/news1/next-energy-news-toshiba...
>>> 0.05 * 200 * 24 * 365 * 40

3504000.0

за 3.5 лимона баксов в серверную на 40 лет.
Круто.
Зато чистое бесперебойное питание и упсов не нужно. :-)))


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено xGa , 01-Окт-09 13:10 
мейби для чего то подобного:
http://zv.innovaterussia.ru/project/4538

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Frank , 01-Окт-09 15:18 
чтоб ютуб не подлагивал

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено EuPhobos , 01-Окт-09 12:34 
На убунту 9.04 -rt немного битое, Кернел Паник возникает при попытке скопировать некий объём информации через ssh на машину с u9.04-rt, однако стабильно работает в u8.04-rt.
Да и в репозитории 9.04, нет надписи "Поддерживается сообществом", а в 8.04 есть такая надпись, может потому что LTS и для него больше постарались.
Больше экспериментов с u9.04-rt я сам не ставил.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено fidaj , 01-Окт-09 13:12 
>На убунту 9.04 -rt немного битое, Кернел Паник возникает при попытке скопировать
>некий объём информации через ssh на машину с u9.04-rt, однако стабильно
>работает в u8.04-rt.
>Да и в репозитории 9.04, нет надписи "Поддерживается сообществом", а в 8.04
>есть такая надпись, может потому что LTS и для него больше
>постарались.
>Больше экспериментов с u9.04-rt я сам не ставил.

uname -a
Linux nonamehost 2.6.31-rt #1 SMP PREEMPT RT Sun Sep 20 10:58:24 EEST 2009 x86_64 GNU/Linux
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти"
Отправлено Anon , 01-Окт-09 13:14 
На убунту 9.04 rt - не стабильное.
Ubuntu Studio использует это ядро и есть проблемы с зависанием на ряде машин, в том числе и у меня.

http://forum.ubuntu.ru/index.php?topic=68168.msg517297#msg51...


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти"
Отправлено fidaj , 01-Окт-09 13:21 
>На убунту 9.04 rt - не стабильное.
>Ubuntu Studio использует это ядро и есть проблемы с зависанием на ряде
>машин, в том числе и у меня.
>
>http://forum.ubuntu.ru/index.php?topic=68168.msg517297#msg51...

Какая именно там версия ядра?


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено аноним , 01-Окт-09 13:26 
Замените в тексте новости apt-get на aptitude.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Gular , 01-Окт-09 14:10 
сейчас набежит народ и будет доказывать с пеной у рта, что aptitude ненужен. что apt-get хватает.
а я согласен с этим сообщением.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Колбасов , 01-Окт-09 14:54 
А может кто-нибудь объяснит - максимальное гарантированное время реакции порядка 2 микросекунд чего и максимальную задержку около 17 микросекунд чего?

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Шурек Табуреткин , 01-Окт-09 15:57 
Кстати брэйнфак патч - полный "шит" на данном этапе. Его пилить и пилить еще. Система с ним работает не совсем должным образом, в Virtualbox вообще не хочет шатдауниться винда и т.д., много недоработок. Ставил недавно, потом вернулся на 2.6.30.8 и скажу честно, доволен им более чем полностью.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено XORIRIX , 01-Окт-09 18:21 
Улыбнула однако новость. OpenSUSE уже сколько лет имеет RT ядра, а "великий и могучий" дебиан только только обзавелся.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Crazy Alex , 01-Окт-09 20:53 
Ну логично, в общем-то. Реалтайм далеко не всем нужен, так что вероятносьт, чо его на добровольной основе станут поддерживать для Дебиана не слишком велика. Сусь же линуксом торгует, соответственно из-за поддержки более интересна для тех, кто в продакшн RT-linux сует. Вот теперь кто-то решил работать с дебианом - будет и для него.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 02-Окт-09 00:02 
XORIRIX не путайте людей. Это "Немецкая компания Pengutronix" обзавелась, а не Debian. В официальном репозитории этих пакетов нет.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Marrenoloth , 02-Окт-09 02:03 
Господа! Давайте не ссориться! RT операционные системы нужны только в промышленности и областях, где нужно гарантированная скорость выполнения какой - то задачи. Т.е. если что-то не влезло по скорости в цикл ядра - страшно материмся, что какой-то гад тормозил систему. Посмертно для гада. На десктопах, серверах и прочей инфраструктурной россыпи применения RT не вижу. Хотя, некоторые сервера, переваривающие фиксированный объем информации за единицу времени, можно перевести на RT. Но, вопрос спорен...
ИМХО.

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 02-Окт-09 02:44 
Для звукозаписи и захвата видео они на десктопе нужны

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Аноним , 02-Окт-09 09:42 
Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или все не так просто?

"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Анонимусо , 02-Окт-09 13:36 
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?

http://rt.wiki.kernel.org/


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Анонимусо , 02-Окт-09 13:39 
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?

http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch


"Для Debian GNU/Linux представлены пакеты Linux ядра, ориенти..."
Отправлено Анонимусо , 02-Окт-09 13:41 
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?

http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO