Немецкая компания 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
а какое из этих ядер подойдет на убунту 9.04 32 бит?
посмотри в синаптике. там есть рт патчи
А какой вообще от них реальный толк?
От реального времени?
при сильных нагрузках отклик системы будет быстрее. например у меня на обычном ядре при интенсивных операциях с дисками все остальное буквально еле шевелется, даже мышка подрагивает...
>например у меня на обычном ядре при интенсивных операциях с дисками все остальное буквально еле шевелется, даже мышка подрагивает...Тебе и реалтайм не поможет )) У тебя не настроена vm (свапы/кеши пропорции итп) и возможно не работает dma.
>У тебя не настроена 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 жесткого я себе плохо представляю) проц бы загружался по полной (во всяком случае один из трех).
>У меня вообще нет свопа.У тебя нет выгрузки на диск анонимных страниц. А readonly секции кода программ, и прочие отображаемые в память файлы отлично вытесняются на диск для освобождения кеша. И при особенно не удачной конфигурации, ядро их гоняет туда и обратно непрерывно.
Чтобы считать ПРАВИЛЬНО, надо знать как работает vm система в linux, тогда и настроишь коэфициенты /proc/sys/vm правильно, и свап не будешь выключать.
Можно поподробнее? Меня этот вопрос очень интересует.
На рабочей машине 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 тоже не лучше.
>[оверквотинг удален]
>Запускаю две виртуальные машины, под каждую выделено 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% от текущего объема ОЗУ... При такой настройке кеш никогда не сброситься... Или я ошибаюсь?
Для начала может быть попробовать опции по умолчанию? - Что они покажут?
>Для начала может быть попробовать опции по умолчанию? - Что они покажут?По-умолчанию такая же ситуация - при загрузке памяти более 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).
Про то, что оно указывается в процентах от ОЗУ нигде не встречал.
Думаю если уменьшить тягу к увеличению кеша, то все уместиться в ОЗУ, и не будет так медлить при работе. Вот и интересуюсь как это сделать.
>>Для начала может быть попробовать опции по умолчанию? - Что они покажут?
>
>По-умолчанию такая же ситуация - при загрузке памяти более 50% производительность падает.
>У меня подобная ситуация - но с одним "НО" - у меня это не зависит от текущего объема занимаемого ОЗУ - все тормоза и рост iowait начинаются строго с того момента как начинает использоваться активно сброс/чтение swap... Иногда даже невозможно дальше работать - откликов нет ни на клавиатуру ни на мышу...
На счет vfs_cache_pressure утверждать ничего не буду - так как попадались статьи, за разные годы их написания, и в каждой статье были разные значения этой опции; и в том числе тоже попадалось о патче позволяющем увеличивать значение этого параметра больше 100%...
Просто похоже что с учетом развития ядра эта опция принимала разную смысловую нагрузку... Пусть гуру меня поправят, если я ошибаюсь...
> все тормоза и рост iowait начинаются строго с того момента как начинает использоваться
> активно сброс/чтение swapУ меня аналогично, и я думаю, что сброс и начинается от того, что в этот момент недостаточно свободной памяти, по той причине, что зарезервировано много cached memory.
Еще хочу обратить внимание, что если приложениями используется 700-800 Мб, то и cached не более 400 МБ. Если же запустить тяжёлые процессы (в сумме требующие > 1,5 Гб), то и cached memory увеличивается до 1,0-1,3 ГБ и вот тут начинается активное использование swap.
>> все тормоза и рост 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
А все остальное по умолчанию...
Не знаю...
Крутил вертел разные значения - при одних одни глюки при других - другие...(то перестает выделять память - то выдает, но тупит страшнее всего)
Вернул значения по умолчанию - хоть и глюков стало меньше, но тормоза еще те, когда доходит до свопа...
>[оверквотинг удален]
>- 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;
}
робототехника, производственные процессы, возможно даже САПР.
> возможно даже САПР.Зачем для САПР режим жесткого реального времени?
А как вы считаете стоит ли на него перейти на десктопе? Может быть там менеджер задач более приспособлен для пользователя?
Или все-таки это будет бесполезно?
Мне главное, чтоб отзывчивость была выше, и чтобы фильмы не тормозили, когда у меня в КДЕ обои меняются.
Апгрейд тебе в помощь, а рт-ядро не даст тебе желаемого результата.
Попробуй 31-ю ветку ядра кстати, говорят, отзывчивость там лучше намного.
Такие ядра нужны только в критичных областях. Ну вот пример атомная станция: нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для этого нужно гарантированное время отклика системы. Как только пришёл ахтунг - система отреагирует и не будет ждать пока какой то процесс отвиснет.На десктопах оно не нужно
Ну у меня конечно не атомная станция, но я тоже не хочу чтобы у меня компьютер тормозил. Это при том что 3 процессора и 6 гиг оперативы.
И что, неужто тормозит? ))
Тормозит :(
http://linuxforum.ru/index.php?showtopic=100776
Что сделать даже и не знаю.
>И что, неужто тормозит? ))И если из локалки много фильмов одновременно качаю ослом - тоже бывает, что мышка дергаться начинает и отрисовка замедляется существенно.
>И если из локалки много фильмов одновременно качаю ослом - тоже бывает,
>что мышка дергаться начинает и отрисовка замедляется существенно.система должна быть сбалансированная.
3 процессора, 6 гигов, а было бы 4 диска да 10 или 5 рейд, и работало бы всё намного веселее
>>И если из локалки много фильмов одновременно качаю ослом - тоже бывает,
>>что мышка дергаться начинает и отрисовка замедляется существенно.
>
>система должна быть сбалансированная.
>3 процессора, 6 гигов, а было бы 4 диска да 10 или
>5 рейд, и работало бы всё намного веселеесбалансированная - да. 1+0 рейд - да. а вот 5 - нет, это компромиссное решение и тормоз. и там выше насчет vm ты тоже слишком категоричен.
hdparm -t твой диск
выложи сюда, тогда будет яснее.
>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 или рейзер.
>>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 режим ?
>[оверквотинг удален]
>>у меня тоже самое, вот 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 битное :)
попробуйте 31-е ядро с браинфак шедулером. Многие пишут, что флеш например на полный экран начинает работать без тормозов и загрузка ядер равномернее.ps правда у меня в убунте 9.10 флеш и без патчей нормально проигрывается (i915)
>попробуйте 31-е ядро с браинфак шедулером. Многие пишут, что флеш например на
>полный экран начинает работать без тормозов и загрузка ядер равномернее.
>
>ps правда у меня в убунте 9.10 флеш и без патчей нормально
>проигрывается (i915)Да - но только обращаю ваше внимание что это, на сколько я знаю, не относится к RT ядру...
Патчи браинфак на RT ядро не подходят...
>Такие ядра нужны только в критичных областях. Ну вот пример атомная станция:
>нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для
>этого нужно гарантированное время отклика системы. Как только пришёл ахтунг -
>система отреагирует и не будет ждать пока какой то процесс отвиснет.
>
>
>На десктопах оно не нужноЕще как нужно!
Я попробовал поставить. Загрузилось, но вот модуль Nvidia не смог скомпилироваться. Брал последние тестовые дрова.
>Я попробовал поставить. Загрузилось, но вот модуль 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(
Окуел..., там всего две строки поменять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;
>[оверквотинг удален]
> struct completion completion;
>-#if defined(CONFIG_PREEMPT_RT)
>- raw_spinlock_t lock;
>-#else
> spinlock_t
> lock;
>-#endif
> S032
> count;
> } os_sema_t;И Шо я вас таки не понял....
К чему такая фамильярность?
Патч не мой!
Говорю о том на чем система стабильно работать начала на том указанном ядре!
За что купил - за то и продал!К тому же не тяжело попробовать тот и другой вариант! - Руки не отсохнут...
Убийственного в этом ничего нет...
>[оверквотинг удален]
>>-#else
>> spinlock_t
>> lock;
>>-#endif
>> S032
>> count;
>> } os_sema_t;
>
>И Шо я вас таки не понял....
>К чему такая фамильярность?Ну шо ты..., я ж любя ж :)
>Я попробовал поставить. Загрузилось, но вот модуль Nvidia не смог скомпилироваться. Брал
>последние тестовые дрова.Новость!
ftp://download.nvidia.com/XFree86/Linux-x86_64/190.42/
Вот эти дрова собираются под RT ядром без каких-либо шаманств :)
>Такие ядра нужны только в критичных областях. Ну вот пример атомная станция:
>нештатная ситуация и через секунду всё взорвется, а компьютер тормозит. Для
>этого нужно гарантированное время отклика системы. Как только пришёл ахтунг -
>система отреагирует и не будет ждать пока какой то процесс отвиснет.Хозяева атомной станции вполне могут раскошелиться на QNX. Он специально создавался для таких целей, в отличие от поделок на основе линуха.
А вот, кто ж его знает. Сверкомпактные необслуживаемые атомные станции "заснул в подвал и дом на сорок лет обеспечен дешевым электричеством" как бы уже пытаются делать, например http://www.nextenergynews.com/news1/next-energy-news-toshiba...Причем основная ставка именно на дешевизну по сравнению с электричеством по линии. То есть ставим потому, что экономим, типа! А там где экономим - линукс вместо коммерческих ОС сам собой вылезать начинает :) А тут, глядишь, и база готова, ставишь Debian "Atomic Edition" и вперед!
>Сверкомпактные необслуживаемые атомные станции "заснул в подвал и дом на сорок лет >обеспечен дешевым электричеством" как бы уже пытаются делать, например >http://www.nextenergynews.com/news1/next-energy-news-toshiba...
>>> 0.05 * 200 * 24 * 365 * 403504000.0
за 3.5 лимона баксов в серверную на 40 лет.
Круто.
Зато чистое бесперебойное питание и упсов не нужно. :-)))
мейби для чего то подобного:
http://zv.innovaterussia.ru/project/4538
чтоб ютуб не подлагивал
На убунту 9.04 -rt немного битое, Кернел Паник возникает при попытке скопировать некий объём информации через ssh на машину с u9.04-rt, однако стабильно работает в u8.04-rt.
Да и в репозитории 9.04, нет надписи "Поддерживается сообществом", а в 8.04 есть такая надпись, может потому что LTS и для него больше постарались.
Больше экспериментов с u9.04-rt я сам не ставил.
>На убунту 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"
На убунту 9.04 rt - не стабильное.
Ubuntu Studio использует это ядро и есть проблемы с зависанием на ряде машин, в том числе и у меня.http://forum.ubuntu.ru/index.php?topic=68168.msg517297#msg51...
>На убунту 9.04 rt - не стабильное.
>Ubuntu Studio использует это ядро и есть проблемы с зависанием на ряде
>машин, в том числе и у меня.
>
>http://forum.ubuntu.ru/index.php?topic=68168.msg517297#msg51...Какая именно там версия ядра?
Замените в тексте новости apt-get на aptitude.
сейчас набежит народ и будет доказывать с пеной у рта, что aptitude ненужен. что apt-get хватает.
а я согласен с этим сообщением.
А может кто-нибудь объяснит - максимальное гарантированное время реакции порядка 2 микросекунд чего и максимальную задержку около 17 микросекунд чего?
Кстати брэйнфак патч - полный "шит" на данном этапе. Его пилить и пилить еще. Система с ним работает не совсем должным образом, в Virtualbox вообще не хочет шатдауниться винда и т.д., много недоработок. Ставил недавно, потом вернулся на 2.6.30.8 и скажу честно, доволен им более чем полностью.
Улыбнула однако новость. OpenSUSE уже сколько лет имеет RT ядра, а "великий и могучий" дебиан только только обзавелся.
Ну логично, в общем-то. Реалтайм далеко не всем нужен, так что вероятносьт, чо его на добровольной основе станут поддерживать для Дебиана не слишком велика. Сусь же линуксом торгует, соответственно из-за поддержки более интересна для тех, кто в продакшн RT-linux сует. Вот теперь кто-то решил работать с дебианом - будет и для него.
XORIRIX не путайте людей. Это "Немецкая компания Pengutronix" обзавелась, а не Debian. В официальном репозитории этих пакетов нет.
Господа! Давайте не ссориться! RT операционные системы нужны только в промышленности и областях, где нужно гарантированная скорость выполнения какой - то задачи. Т.е. если что-то не влезло по скорости в цикл ядра - страшно материмся, что какой-то гад тормозил систему. Посмертно для гада. На десктопах, серверах и прочей инфраструктурной россыпи применения RT не вижу. Хотя, некоторые сервера, переваривающие фиксированный объем информации за единицу времени, можно перевести на RT. Но, вопрос спорен...
ИМХО.
Для звукозаписи и захвата видео они на десктопе нужны
Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или все не так просто?
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?
>Такое же ядро можно самому сотсряпать? В конфиге выбрать preemptible kernel? Или
>все не так просто?