[sisyphus] ядро std-def и io scheduler

[sisyphus] ядро std-def и io scheduler

[Anton Chernyshov]

[anton@rivendale ~]$ dmesg | grep sched
[    1.201885] io scheduler noop registered (default)
[    1.201902] io scheduler cfq registered
[anton@rivendale ~]$ uname -a
Linux rivendale 2.6.35-std-def-alt9 #1 SMP Thu Dec 9 08:52:44 UTC 2010
x86_64 GNU/Linux
[anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
[noop] cfq

В использовании noop scheduler по умолчанию есть какой-то сокровенный
смысл или это просто бага?

-- 
С уважением,
Чернышов Антон

Re: [sisyphus] ядро std-def и io scheduler

[Michael Shigorin]

On Wed, Jan 05, 2011 at 11:20:33AM +0300, Anton Chernyshov wrote:
> 2.6.35-std-def-alt9
> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> [noop] cfq

Подтверждаю.

> В использовании noop scheduler по умолчанию есть какой-то
> сокровенный смысл или это просто бага?

Похоже на ляп.  Смысл в таком есть разве что внутри kvm/xen.

PS: ещё у меня порой звук "подмерзает", чего не так давно
не наблюдалось.  Надо будет собраться да сходить на un-def.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ядро std-def и io scheduler

[Anton Chernyshov]

5 января 2011 г. 12:04 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Wed, Jan 05, 2011 at 11:20:33AM +0300, Anton Chernyshov wrote:
>> 2.6.35-std-def-alt9
>> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
>> [noop] cfq
>
> Подтверждаю.

Багу надо вешать или этого письма достаточно?

>> В использовании noop scheduler по умолчанию есть какой-то
>> сокровенный смысл или это просто бага?
>
> Похоже на ляп.  Смысл в таком есть разве что внутри kvm/xen.
>
> PS: ещё у меня порой звук "подмерзает", чего не так давно
> не наблюдалось.  Надо будет собраться да сходить на un-def.

На un-def еще и вытеснение включено (которое PREEMPT), так что по идее
там поживее все должно быть.


-- 
С уважением,
Чернышов Антон

Re: [sisyphus] ядро std-def и io scheduler

[Ildar Mulyukov]

On 05.01.2011 15:10:31, Anton Chernyshov wrote:
> 5 января 2011 г. 12:04 пользователь Michael Shigorin  
> <mike@osdn.org.ua> написал:
> > On Wed, Jan 05, 2011 at 11:20:33AM +0300, Anton Chernyshov wrote:
> >> 2.6.35-std-def-alt9
> >> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> >> [noop] cfq
> >
> > Подтверждаю.
> 
> Багу надо вешать или этого письма достаточно?

Для пакетов std-def писем недостаточно. Надо вешать.
-- 
Ildar

Re: [sisyphus] ядро std-def и io scheduler

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Wed, Jan 05, 2011 at 11:04:53AM +0200, Michael Shigorin wrote:

>> В использовании noop scheduler по умолчанию есть какой-то
>> сокровенный смысл или это просто бага?
MS> Похоже на ляп.  Смысл в таком есть разве что внутри kvm/xen.

Еще на SSD и рейдах с батарейкой, AFAIR.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Michael Shigorin]

On Wed, Jan 05, 2011 at 01:11:10PM +0300, Денис Смирнов wrote:
> >> В использовании noop scheduler по умолчанию есть какой-то
> >> сокровенный смысл или это просто бага?
> MS> Похоже на ляп.  Смысл в таком есть разве что внутри kvm/xen.
> Еще на SSD и рейдах с батарейкой, AFAIR.

Да, спасибо.

Кстати -- повесь чё-нить на инсталер, ряд случаев вполне можно
учитывать автоматом.  И до кучи:

http://stackoverflow.com/questions/154163/detect-virtualized-os-from-an-application
http://people.redhat.com/~rjones/virt-what/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ядро std-def и io scheduler

[Michael Shigorin]

On Wed, Jan 05, 2011 at 12:10:31PM +0300, Anton Chernyshov wrote:
> >> 2.6.35-std-def-alt9
> >> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> >> [noop] cfq
> > Подтверждаю.
> Багу надо вешать или этого письма достаточно?

IMHO стоит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ядро std-def и io scheduler

[Aeliya Grevnyov]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

05.01.2011 15:20, Anton Chernyshov пишет:
> [anton@rivendale ~]$ dmesg | grep sched
> [    1.201885] io scheduler noop registered (default)
> [    1.201902] io scheduler cfq registered
> [anton@rivendale ~]$ uname -a
> Linux rivendale 2.6.35-std-def-alt9 #1 SMP Thu Dec 9 08:52:44 UTC 2010
> x86_64 GNU/Linux
> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> [noop] cfq
> 
> В использовании noop scheduler по умолчанию есть какой-то сокровенный
> смысл или это просто бага?
> 
шо, опять?
http://lists.altlinux.org/pipermail/sisyphus/2010-November/350472.html


kernel-image-std-def
2010-11-01 Michail Yakushin <silicium at altlinux.ru> 1:2.6.35-alt8
      - 2.6.35.8
      - compiled-in cfq scheduler
      - add nvidia backlight support
      - add mac book air 3,1 support


kernel-image-un-def
2010-11-23 Anton V. Boyarshinov <boyarsh at altlinux.ru> 1:2.6.35-alt9
      - 2.6.35.9
      - default io sched set to deadline


- -- 
WBR,
Aeliya gray_graff Grevnyov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0kWn8ACgkQE+rFeART/CkiZACg305ZX7UB1ChpBAkM1qCCsdm7
4BQAn0f0yjUksX7nkKY6ve/P4g/RBDxa
=sy47
-----END PGP SIGNATURE-----

[-- Attachment #2: 0x0453FC29.asc --]
[-- Type: application/pgp-keys, Size: 1711 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

В Срд, 05/01/2011 в 18:48 +0700, Aeliya Grevnyov пишет:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 05.01.2011 15:20, Anton Chernyshov пишет:
> > [anton@rivendale ~]$ dmesg | grep sched
> > [    1.201885] io scheduler noop registered (default)
> > [    1.201902] io scheduler cfq registered
> > [anton@rivendale ~]$ uname -a
> > Linux rivendale 2.6.35-std-def-alt9 #1 SMP Thu Dec 9 08:52:44 UTC 2010
> > x86_64 GNU/Linux
> > [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> > [noop] cfq
> > 
> > В использовании noop scheduler по умолчанию есть какой-то сокровенный
> > смысл или это просто бага?
> > 
> шо, опять?

для дефективных ядер это нормально, скажите спасибо что cfq не модулем

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Anton Chernyshov]

5 января 2011 г. 15:40 пользователь Valery V. Inozemtsev
<shrek@altlinux.ru> написал:
> для дефективных ядер это нормально, скажите спасибо что cfq не модулем
>

"Дефективные" - это которые не std-ng? :)

Багу повесил - 24861

-- 
С уважением,
Чернышов Антон

Re: [sisyphus] ядро std-def и io scheduler

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

В Срд, 05/01/2011 в 16:13 +0300, Anton Chernyshov пишет:
> 5 января 2011 г. 15:40 пользователь Valery V. Inozemtsev
> <shrek@altlinux.ru> написал:
> > для дефективных ядер это нормально, скажите спасибо что cfq не модулем
> >
> 
> "Дефективные" - это которые не std-ng? :)

это которые def (чем дальше, тем больше убеждаюсь что от defective)
к сожалению в ALTLinux нет мантейнера ядра который хоть мало мальски
понимал что и зачем он делает. у мантейнеров дефективных ядер вообще
правая рука не знает что делает левая, еще и провалами памяти страдают

> Багу повесил - 24861

ну этак через годик может и рассосется

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Anton Chernyshov]

5 января 2011 г. 16:44 пользователь Valery V. Inozemtsev
<shrek@altlinux.ru> написал:
> это которые def (чем дальше, тем больше убеждаюсь что от defective)
> к сожалению в ALTLinux нет мантейнера ядра который хоть мало мальски
> понимал что и зачем он делает.

Ну так Вы же тоже вроде как майнтейнер ядра?

-- 
С уважением,
Чернышов Антон

Re: [sisyphus] ядро std-def и io scheduler

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

В Срд, 05/01/2011 в 18:33 +0300, Anton Chernyshov пишет:
> 5 января 2011 г. 16:44 пользователь Valery V. Inozemtsev
> <shrek@altlinux.ru> написал:
> > это которые def (чем дальше, тем больше убеждаюсь что от defective)
> > к сожалению в ALTLinux нет мантейнера ядра который хоть мало мальски
> > понимал что и зачем он делает.
> 
> Ну так Вы же тоже вроде как майнтейнер ядра?

"вроде как" и не более того. и то только sdt-ng и только для себя

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Michael Pozhidaev]

Hello, Valery V. Inozemtsev!

>> "Дефективные" - это которые не std-ng? :)
>
> это которые def (чем дальше, тем больше убеждаюсь что от defective)
> к сожалению в ALTLinux нет мантейнера ядра который хоть мало мальски
> понимал что и зачем он делает. у мантейнеров дефективных ядер вообще
> правая рука не знает что делает левая, еще и провалами памяти страдают

Так какие события должны наступить в команде, чтобы пользователи и
разработчики могли бы не решать каждый раз головоломку, какое же ядро
себе взять из пачки доступных?

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/

[sisyphus] "официальное" ядро

[Ildar Mulyukov]

On 06.01.2011 03:50:15, Michael Pozhidaev wrote:
> Так какие события должны наступить в команде, чтобы пользователи и
> разработчики могли бы не решать каждый раз головоломку, какое же ядро
> себе взять из пачки доступных?

Ну что ж, хорошо сформулированный вопрос вынуждает меня поделиться  
опытом.
1. До недавних пор я думал, что, как и раньше, стандартное ядро в Альте  
- std-def. Но это уже не так. Подтверждение тому - Кентавр, у которого  
стандартное - el-smp.
    На std-def висят баги, которыми никто не занимается.
2. Пусть el-smp - ядро, которое, в основном, проработано не нами, но по  
крайней мере мы ожидаем, что оно будет работать. Однако, у него 2  
существенных недостатка:
   а. застряли на версии 2.6.32. В частности, не заводятся наши cgroup.  
Интересно, это можно поправить, не поднимая версии?
   б. отсутствует KVM для i586. Для меня это фатально, поэтому я и с  
него сбежал.
3. В случае проблем в части Xorg, имеет смысл пробовать std-ng. Похоже,  
не я один  пришёл к выводу, что по сумме характеристик это ядро ---  
наиболее подходящее.
4. Есть ещё un-def, но на нём у меня проявляется дефект в Xorg.

По поводу найденных дефектов предлагаю заинтересованных пройти на  
багзиллу.
По поводу "официального" или "рекомендуемого" ядра: боюсь, этот вопрос  
у нас замалчивается (сознательно или несознательно). По крайней мере я  
прямых указаний не встречал.

С уважением,
	Ильдар
-- 
Ildar Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar.mulyukov@gmail.com
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [sisyphus] "официальное" ядро

[Anton Chernyshov]

6 января 2011 г. 8:54 пользователь Ildar Mulyukov <ildar@altlinux.ru> написал:
> 2. Пусть el-smp - ядро, которое, в основном, проработано не нами, но по
> крайней мере мы ожидаем, что оно будет работать. Однако, у него 2
> существенных недостатка:
>  а. застряли на версии 2.6.32. В частности, не заводятся наши cgroup.

У Red Hat к слову - это условный номер версии. Они будут (и уже
делают) кучу бекпортов с последних версий на 2.6.32

-- 
С уважением,
Чернышов Антон

Re: [sisyphus] "официальное" ядро

[Slava Semushin]

6 января 2011 г. 11:54 пользователь Ildar Mulyukov <ildar@altlinux.ru> написал:
[...]
> 3. В случае проблем в части Xorg, имеет смысл пробовать std-ng. Похоже, не я
> один  пришёл к выводу, что по сумме характеристик это ядро --- наиболее
> подходящее.

C ядра std-def ушел с полгода назад (если не больше), когда оно у меня
тупо не загрузилось. С тех пор так его и не пробовал, сижу на std-ng.
Спасибо, Валерию, за то что оно just works.


-- 
Slava Semushin

Re: [sisyphus] "официальное" ядро

[diver]

2011/1/6 Slava Semushin:
> C ядра std-def ушел с полгода назад (если не больше), когда оно у меня
> тупо не загрузилось. С тех пор так его и не пробовал, сижу на std-ng.
> Спасибо, Валерию, за то что оно just works.

+1


-- 
LRU: #407670

Re: [sisyphus] сравнительные списки ядра-модули

[Денис Смирнов]

[-- Attachment #1.1: Type: text/plain, Size: 3756 bytes --]


MS> PS: вот скриптик, который в процессе работы над mkimage-profiles
MS> помог с выбором "нулевого приближения" наборов флаворо-модулей:

У меня скриптик круче :-P

На сейчас обидено что в ovz-el есть не все что есть в el-smp -- раз. И зря
compcache собран только для tmc-tc -- два.

Ну и мне для полного счастья сейчас не хватает варианта ovz-el собранного
с поддержкой xen domU, дабы таки запустить альт на Amazon EC2.

MODULE              el-smp   hpc-skif ovz-el   std-def  std-ng   std-pae  tmc-tc   un-def   xen-dom0 
alsa                    Ok       Ok       Ok       Ok     -----    i586     i586       Ok       Ok   
bcmwl                   Ok     -----      Ok       Ok     -----    i586     -----      Ok       Ok   
compcache             -----    -----    -----    -----    -----    -----    i586     -----    -----  
dahdi                   Ok     -----      Ok       Ok     -----    i586     -----    -----      Ok   
drbd83                  Ok       Ok     -----    -----    -----    -----    -----    -----      Ok   
drm                     Ok       Ok       Ok       Ok     -----    i586     i586       Ok       Ok   
drm-nouveau             Ok     -----    -----      Ok     -----    i586     -----      Ok     -----  
drm-radeon            -----    -----    -----      Ok     -----    i586     -----      Ok     -----  
fglrx                 -----      Ok     -----    -----    -----    -----    i586     -----    -----  
ide                   -----    -----      Ok       Ok     -----    i586     -----      Ok     -----  
igb                   -----    -----    -----      Ok     -----    i586     -----      Ok       Ok   
ipset                   Ok     -----      Ok       Ok     -----    i586     -----      Ok     -----  
kvm                   x86_64   -----      Ok       Ok     -----    i586     -----      Ok       Ok   
lirc                    Ok     -----      Ok       Ok     -----    i586     -----    -----    -----  
lustre                -----      Ok     -----    -----    -----    -----    -----    -----    -----  
ndiswrapper             Ok     -----      Ok       Ok     -----    i586     -----    -----    -----  
nvidia                  Ok       Ok       Ok       Ok       Ok     i586     i586       Ok       Ok   
omnibook                Ok     -----      Ok       Ok     -----    i586     -----      Ok     -----  
oss                   -----    -----    -----    -----    -----    -----    -----    -----      Ok   
pf_ring               -----    -----    -----      Ok     -----    i586     -----      Ok     -----  
rtl8168                 Ok     -----    -----      Ok     -----    i586     -----    -----    -----  
rtl8192                 Ok     -----      Ok       Ok     -----    i586     -----      Ok     -----  
staging               -----    -----    -----      Ok     -----    i586     -----      Ok     -----  
subfs                 -----    -----    -----      Ok     -----    i586     -----      Ok       Ok   
tp_smapi                Ok     -----      Ok       Ok     -----    i586     -----      Ok     -----  
v4l                     Ok     -----    -----      Ok     -----    i586     -----      Ok       Ok   
vhba                    Ok     -----    -----      Ok     -----    i586     -----      Ok     -----  
virtualbox              Ok     -----      Ok       Ok     -----    i586     -----    -----    -----  
virtualbox-addition     Ok     -----      Ok       Ok     -----    i586     -----    -----    -----  
xtables-addons        -----    -----    -----      Ok     -----    i586     -----      Ok     -----  

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #1.2: kernel-modules-list --]
[-- Type: text/plain, Size: 1297 bytes --]

#!/usr/bin/perl -w
use strict;

my %flavours;
my %pkgs;

open( IN, "utils/list-pkg-kernel |" );
while (<IN>) {
    chomp;
    /^([^\s]+)\s+(.+)/;
    my $arch = $1;
    next if $arch eq 'arm';
    my $name = $2;
    my $flavour;

    die "$_" unless $name =~ s/-([^-]+-[^-]+)$//;
    $flavour = $1;

    $flavours{$flavour} = 1;

    $pkgs{$name}->{$flavour}->{$arch} = 1;
}
close(IN);

# Рассчет размера поля с именем модуля
my $l = 0;
foreach ( keys %pkgs ) {
    my $l2 = length $_;
    $l = $l2 if $l2 > $l;
}
$l++;

printf "%-${l}s", "MODULE";

my @flavours = sort keys %flavours;
foreach (@flavours) {
    printf "%-9s", $_;
}
print "\n";

#print "@flavours\n";

foreach ( sort keys %pkgs ) {
    printf "%-${l}s", $_;
    foreach my $f (@flavours) {
        if ( defined $pkgs{$_}->{$f} ) {
            my $t = $pkgs{$_}->{$f};
            if ( defined $t->{x86_64} ) {
                if ( defined $t->{i586} ) {
                    print "    Ok   ";
                }
                else {
                    print "  x86_64 ";
                }
            }
            else {
                print "  i586   ";
            }
        }
        else {
            print "  -----  ";
        }
    }
    print "\n";
}


[-- Attachment #1.3: list-pkg-kernel --]
[-- Type: text/plain, Size: 186 bytes --]

#!/bin/sh
find /var/lib/altlinux/sisyphus/files/ \
	-type f \
	| grep /kernel-modules \
	| grep -v .src.rpm$ \
	| xargs rpm -qp --qf '%{ARCH}\t%{NAME}\n' \
	| sed 's/kernel-modules-//'


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[sisyphus] сравнительные списки ядра-модули

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

On Thu, Jan 06, 2011 at 11:54:12AM +0600, Ildar Mulyukov wrote:
> 3. В случае проблем в части Xorg, имеет смысл пробовать std-ng.
> Похоже,  не я один  пришёл к выводу, что по сумме характеристик
> это ядро ---  наиболее подходящее.
> 4. Есть ещё un-def, но на нём у меня проявляется дефект в Xorg.

К сожалению, для них обоих мне чего-то да не хватает: либо subfs
(которое может требовать некоторых усилий для сборки с новыми
ядрами, каковые обычно предпринимает led@), либо virtualbox
(почему его не собирают для un-def, не знаю).

PS: вот скриптик, который в процессе работы над mkimage-profiles
помог с выбором "нулевого приближения" наборов флаворо-модулей:

i586/RPMS $ kernel-modules-chart.sh -m
alsa: el-smp hpc-skif ovz-el std-def std-pae tmc-tc un-def xen-dom0
bcmwl: el-smp ovz-el std-def std-pae un-def xen-dom0
compcache: tmc-tc
dahdi: el-smp ovz-el std-def std-pae xen-dom0
drbd83: el-smp hpc-skif xen-dom0
drm: el-smp hpc-skif ovz-el std-def std-pae tmc-tc un-def xen-dom0
drm-nouveau: el-smp std-def std-pae un-def
drm-radeon: std-def std-pae un-def
fglrx: hpc-skif tmc-tc
ide: ovz-el std-def std-pae un-def
igb: std-def std-pae un-def xen-dom0
ipset: el-smp ovz-el std-def std-pae un-def
kvm: ovz-el std-def std-pae un-def xen-dom0
lirc: el-smp ovz-el std-def std-pae
lustre: hpc-skif
ndiswrapper: el-smp ovz-el std-def std-pae
nvidia: el-smp hpc-skif ovz-el std-def std-ng std-pae tmc-tc un-def xen-dom0
omnibook: el-smp ovz-el std-def std-pae un-def
oss: xen-dom0
pf_ring: std-def std-pae un-def
rtl8168: el-smp std-def std-pae
rtl8192: el-smp ovz-el std-def std-pae un-def
staging: std-def std-pae un-def
subfs: std-def std-pae un-def xen-dom0
tp_smapi: el-smp ovz-el std-def std-pae un-def
v4l: el-smp std-def std-pae un-def xen-dom0
vhba: el-smp std-def std-pae un-def
virtualbox: el-smp ovz-el std-def std-pae
virtualbox-addition: el-smp ovz-el std-def std-pae

i586/RPMS $ kernel-modules-chart.sh -f
el-smp: alsa bcmwl dahdi drbd83 drm drm-nouveau ipset lirc ndiswrapper nvidia omnibook rtl8168 rtl8192 tp_smapi v4l vhba virtualbox virtualbox-addition
hpc-skif: alsa drbd83 drm fglrx lustre nvidia
ovz-el: alsa bcmwl dahdi drm ide ipset kvm lirc ndiswrapper nvidia omnibook rtl8192 tp_smapi virtualbox virtualbox-addition
std-def: alsa bcmwl dahdi drm drm-nouveau drm-radeon ide igb ipset kvm lirc ndiswrapper nvidia omnibook pf_ring rtl8168 rtl8192 staging subfs tp_smapi v4l vhba virtualbox virtualbox-addition xtables-addons
std-ng: nvidia
std-pae: alsa bcmwl dahdi drm drm-nouveau drm-radeon ide igb ipset kvm lirc ndiswrapper nvidia omnibook pf_ring rtl8168 rtl8192 staging subfs tp_smapi v4l vhba virtualbox virtualbox-addition xtables-addons
tmc-tc: alsa compcache drm fglrx nvidia
un-def: alsa bcmwl drm drm-nouveau drm-radeon ide igb ipset kvm nvidia omnibook pf_ring rtl8192 staging subfs tp_smapi v4l vhba xtables-addons

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: kernel-modules-chart.sh --]
[-- Type: application/x-sh, Size: 867 bytes --]

[sisyphus] [JT] не надо так

[Michael Shigorin]

On Wed, Jan 05, 2011 at 05:28:50PM +0200, Victor Forsiuk wrote:
> Тогда, что Вы тут делаете? Вам место в более достойной команде.

Витя, тогда и меня разгоняй.

-- 
http://egorfine.com/ru/articles/worse-than-failure/

Re: [sisyphus] ядро std-def и io scheduler

[Michael Shigorin]

On Thu, Jan 06, 2011 at 03:50:15AM +0600, Michael Pozhidaev wrote:
> Так какие события должны наступить в команде, чтобы
> пользователи и разработчики могли бы не решать каждый раз
> головоломку, какое же ядро себе взять из пачки доступных?

Стабилизация компаний в экосистеме _и_ достаточное взаимоуважение.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] " официальное

[Valery Pipin]

On Thursday 06 January 2011 20:50:45 diver wrote:
> 2011/1/6 Slava Semushin:
> > C ядра std-def ушел с полгода назад (если не больше), когда оно у меня
> > тупо не загрузилось. С тех пор так его и не пробовал, сижу на std-ng.
> > Спасибо, Валерию, за то что оно just works.
> 
> +1
-1
глючит оно на нвидии(GM9400),  кде4. Более того тормозит (замерзает курсор 
мыши) в последних версиях, начиная с  2.6.36. 
 

Re: [sisyphus] " официальное

[diver]

2011/1/6 Valery Pipin:
> On Thursday 06 January 2011 20:50:45 diver wrote:
>> 2011/1/6 Slava Semushin:
>> > C ядра std-def ушел с полгода назад (если не больше), когда оно у меня
>> > тупо не загрузилось. С тех пор так его и не пробовал, сижу на std-ng.
>> > Спасибо, Валерию, за то что оно just works.
>>
>> +1
> -1
> глючит оно на нвидии(GM9400),  кде4. Более того тормозит (замерзает курсор
> мыши) в последних версиях, начиная с  2.6.36.
У меня все ровно....
Какой драйвер для видео используете? И на каком ядре не глючит?



-- 
LRU: #407670

Re: [sisyphus] " официальное

[Valery Pipin]

On Thursday 06 January 2011 21:19:28 diver wrote:
> 2011/1/6 Valery Pipin:
> > On Thursday 06 January 2011 20:50:45 diver wrote:
> >> 2011/1/6 Slava Semushin:
> >> > C ядра std-def ушел с полгода назад (если не больше), когда оно у меня
> >> > тупо не загрузилось. С тех пор так его и не пробовал, сижу на std-ng.
> >> > Спасибо, Валерию, за то что оно just works.
> >> 
> >> +1
> > 
> > -1
> > глючит оно на нвидии(GM9400),  кде4. Более того тормозит (замерзает
> > курсор мыши) в последних версиях, начиная с  2.6.36.
> 
> У меня все ровно....
> Какой драйвер для видео используете?
260.19.29
> И на каком ядре не глючит?
стабильно глючит на std-ng. Я его периодически пробую, начитавшись хвалебных 
отзывов и ориентируясь на название, после удаляю, хорошо что есть std-def и 
сегодня вот поставил el-smp, которое старовато для моего оборудования, но все 
же пока глюков не заметил

Re: [sisyphus] ядро std-def и io scheduler

[Michael Pozhidaev]

Hello, Michael Shigorin!

>> Так какие события должны наступить в команде, чтобы
>> пользователи и разработчики могли бы не решать каждый раз
>> головоломку, какое же ядро себе взять из пачки доступных?
>
> Стабилизация компаний в экосистеме _и_ достаточное взаимоуважение.

Миша, а можно мне неразумный вопрос: насколько тяжело наработки shrek@ в
его ядре втянуть в std-def? 

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/

Re: [sisyphus] сравнительные списки ядра-модули

[Michael Shigorin]

On Thu, Jan 06, 2011 at 03:53:50PM +0300, Денис Смирнов wrote:
> У меня скриптик круче :-P

(прикрывая голову) Не-не, я что, я ничего :)

> И зря compcache собран только для tmc-tc -- два.

http://kernelnewbies.org/Linux_2_6_33#head-2d401df4d54a65a60c31ce7c591cf7660851cfd8

> MODULE              el-smp   hpc-skif ovz-el   std-def  std-ng   std-pae  tmc-tc   un-def   xen-dom0 
> subfs                 -----    -----    -----      Ok     -----    i586     -----      Ok       Ok   
> virtualbox              Ok     -----      Ok       Ok     -----    i586     -----    -----    -----  

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ядро std-def и io scheduler

[Michael Shigorin]

On Thu, Jan 06, 2011 at 07:46:18PM +0600, Michael Pozhidaev wrote:
> Миша, а можно мне неразумный вопрос: насколько тяжело наработки
> shrek@ в его ядре втянуть в std-def? 

Не знаю, поскольку не отслеживаю состояние ни того, ни другого.

Хорошо бы от деструктива и обвинений в некомпетентности выходить
на то, когда интересно поделиться опытом -- но это многого от
человека требует: и рассказывать труд, и внимать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] ядро std-def и io scheduler

[Andrii Dobrovol`s`kii]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael Shigorin пишет:
> On Thu, Jan 06, 2011 at 07:46:18PM +0600, Michael Pozhidaev wrote:
>> Миша, а можно мне неразумный вопрос: насколько тяжело наработки
>> shrek@ в его ядре втянуть в std-def? 
> 
> Не знаю, поскольку не отслеживаю состояние ни того, ни другого.
> 
> Хорошо бы от деструктива и обвинений в некомпетентности выходить
> на то, когда интересно поделиться опытом -- но это многого от
> человека требует: и рассказывать труд, и внимать.
> 
И увы, у нас что-то становиться мало способных на него...
:(((
А вот облаять... И ведь это у тех кому есть чем поделиться, что
особенно жаль...
- -- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk0lzuIACgkQpBPgR3404hProwEAnpunSagIFW29g/naVd8Jgqoo
UycoP6cZNrb4PiZLdTYBAKCQgMUhGwuru3t9iYvVzJ0aLfkgI4Dg++GhbcpgshGV
=b2Be
-----END PGP SIGNATURE-----

Re: [sisyphus] сравнительные списки ядра-модули

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Thu, Jan 06, 2011 at 03:48:41PM +0200, Michael Shigorin wrote:

>> И зря compcache собран только для tmc-tc -- два.
MS> http://kernelnewbies.org/Linux_2_6_33#head-2d401df4d54a65a60c31ce7c591cf7660851cfd8
                                   ^^^^^^

$ uname -r
2.6.32-ovz-el-alt6

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Ildar Mulyukov]

On 06.01.2011 20:00:28, Michael Shigorin wrote:
> On Thu, Jan 06, 2011 at 07:46:18PM +0600, Michael Pozhidaev wrote:
> > Миша, а можно мне неразумный вопрос: насколько тяжело наработки
> > shrek@ в его ядре втянуть в std-def?
> 
> Не знаю, поскольку не отслеживаю состояние ни того, ни другого.
> 
> Хорошо бы от деструктива и обвинений в некомпетентности выходить
> на то, когда интересно поделиться опытом -- но это многого от
> человека требует: и рассказывать труд, и внимать.

Тут всё просто: опенсорс в чистом виде. Сырцы доступны. А если у кого  
будут конкретные вопросы к Валерию --- не думаю, что он откажется на  
них ответить.
-- 
Ildar

Re: [sisyphus] " официальное

[Vitaly Kuznetsov]

Valery Pipin <pip@iszf.irk.ru> writes:

> сегодня вот поставил el-smp, которое старовато для моего оборудования,
> но все же пока глюков не заметил

el-smp очень условно 2.6.32, там куча всего набекпорчено из старших
ядер.

-- 
Vitaly Kuznetsov, ALT Linux

Re: [sisyphus] ядро std-def и io scheduler

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Anton Chernyshov <flammifer-aPYA7nAdAYY@public.gmane.org> writes:

> [anton@rivendale ~]$ dmesg | grep sched
> [    1.201885] io scheduler noop registered (default)
> [    1.201902] io scheduler cfq registered
> [anton@rivendale ~]$ uname -a
> Linux rivendale 2.6.35-std-def-alt9 #1 SMP Thu Dec 9 08:52:44 UTC 2010
> x86_64 GNU/Linux
> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
> [noop] cfq
>
> В использовании noop scheduler по умолчанию есть какой-то сокровенный
> смысл или это просто бага?

Насколько я знаю, при работающем NCQ у SATA-дисков noop лучше, ибо не
пытается делать лишнюю работу.
Но возможно это верно только для одного диска, хотя точно сказать не
могу.

PS:
$ grep NCQ /var/log/dmesg 
[    1.308504] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] ядро std-def и io scheduler

[Aeliya Grevnyov]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

09.01.2011 03:01, Ivan Fedorov пишет:
> Anton Chernyshov <flammifer-aPYA7nAdAYY@public.gmane.org> writes:
> 
>> [anton@rivendale ~]$ dmesg | grep sched
>> [    1.201885] io scheduler noop registered (default)
>> [    1.201902] io scheduler cfq registered
>> [anton@rivendale ~]$ uname -a
>> Linux rivendale 2.6.35-std-def-alt9 #1 SMP Thu Dec 9 08:52:44 UTC 2010
>> x86_64 GNU/Linux
>> [anton@rivendale ~]$ cat /sys/block/sda/queue/scheduler
>> [noop] cfq
>>
>> В использовании noop scheduler по умолчанию есть какой-то сокровенный
>> смысл или это просто бага?
> 
> Насколько я знаю, при работающем NCQ у SATA-дисков noop лучше, ибо не
> пытается делать лишнюю работу.
> Но возможно это верно только для одного диска, хотя точно сказать не
> могу.
>
все бы хорошо, но для флешек/usb_hdd/etc. тоже noop включается
сейчас не проверял, но тогда при втыкании флешки ядро ругалось на scheduler

- -- 
WBR,
Aeliya gray_graff Grevnyov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0ozIQACgkQE+rFeART/Ckv8gCg137jKi/zW4DG94wBgwO6Au8Y
gmoAn3g+/YAM5Mxa2XpyLUjA69MrJsAc
=gAuQ
-----END PGP SIGNATURE-----

[-- Attachment #2: 0x0453FC29.asc --]
[-- Type: application/pgp-keys, Size: 1711 bytes --]

Re: [sisyphus] сравнительные списки ядра-модули

[Anton V. Boyarshinov]

В Thu, 6 Jan 2011 15:53:50 +0300
"Денис Смирнов" <mithraen@freesource.info> пишет:

> compcache собран только для tmc-tc -- два.
comocache сейчас называется zvram и собран в un-def. Я лично им
пользуюсь.