[Comm] Производительность

[Comm] Производительность

[Vladimir Karpinsky]

Здравствуйте!

Прошу прощения за кросс-пост, --- очень надо решить проблему, отвечайте, 
пожалуйста, в одну рассылку.

Есть проблема: выполняется программа, которая читает файлы данных, 
переформатирует их и записывает в новом формате, --- т.е. имеем арифметику 
+ чтение-запись на диск. Под KDesktop64 (P6 текущий) каждый файл 
обрабатывается 10--15 минут, Centos64 --- 110 секунд, windows --- 7 секунд 
(пишет один и тот же человек). Компьютер не самый слабый, --- на тестах 
(генерация синусоид + запись на диск) этот компьютер быстрее.

model name      : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

CPU0  :  0.0%us,  0.3%sy,  0.0%ni, 46.3%id, 53.3%wa,  0.0%hi,  0.0%si,  0.0%st
CPU1  :  0.3%us,  0.3%sy,  0.3%ni, 43.7%id, 55.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4059536K total,  3942572K used,   116964K free,   196324K buffers
Swap:  2095036K total,    59828K used,  2035208K free,  3226524K cached

Ядро 3.0.36.

Сейчас трудится 3 таких процесса, других особо затратных процессов больше 
нет. Видно, что всё трудится, но производительность чудовищно низкая.

ldd ./sdas2isidl0
         linux-vdso.so.1 =>  (0x00007fff4ebff000)
         libz.so.1 => /lib64/libz.so.1 (0x00007f6a90596000)
         libm.so.6 => /lib64/libm.so.6 (0x00007f6a90314000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6a900f7000)
         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6a8fdf0000)
         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6a8fbda000)
         libc.so.6 => /lib64/libc.so.6 (0x00007f6a8f871000)
         /lib64/ld-linux-x86-64.so.2 (0x00007f6a907c6000)

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[vx8400]

Это с одним процессом такой iowait?
Самодостаточный тестовый пример желательно прислать.

wbr,
Oleg.

28 июля 2012 г., 14:40 пользователь Vladimir Karpinsky
<vkarpinsky@mail.ru> написал:
> Здравствуйте!
>
> Под KDesktop64 (P6 текущий) каждый файл
> обрабатывается 10--15 минут, Centos64 --- 110 секунд, windows --- 7 секунд
> (пишет один и тот же человек). Компьютер не самый слабый, --- на тестах
> (генерация синусоид + запись на диск) этот компьютер быстрее.
>
> model name      : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
>
> CPU0  :  0.0%us,  0.3%sy,  0.0%ni, 46.3%id, 53.3%wa,  0.0%hi,  0.0%si,
> 0.0%st
> CPU1  :  0.3%us,  0.3%sy,  0.3%ni, 43.7%id, 55.3%wa,  0.0%hi,  0.0%si,
> 0.0%st
>

Re: [Comm] Производительность

[Dmitriy Kruglikov]

28 июля 2012 г., 13:57 пользователь vx8400 <vx8400@gmail.com> написал:
> Это с одним процессом такой iowait?
Это с какого-то перрода любая запись срывает крышу и возносит LA к облакам...


-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[Vladimir Karpinsky]

Там 3 одинаковых процесса. Насчёт iowait: м.б. это RAID1 (4 зеркала) так 
себя ведёт?

$cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb2[1] sda2[0]
       2095040 blocks [2/2] [UU]

md2 : active raid1 sdb5[1] sda5[0]
       20478912 blocks [2/2] [UU]

md3 : active raid1 sdb6[1] sda6[0]
       945476480 blocks [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
       8707008 blocks [2/2] [UU]


28.07.2012 15:08, Dmitriy Kruglikov пишет:
> 28 июля 2012 г., 13:57 пользователь vx8400 <vx8400@gmail.com> написал:
>> Это с одним процессом такой iowait?
> Это с какого-то перрода любая запись срывает крышу и возносит LA к облакам...
>
>

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Dmitriy Kruglikov]

28 июля 2012 г., 14:32 пользователь Vladimir Karpinsky
<vkarpinsky@mail.ru> написал:
> Там 3 одинаковых процесса. Насчёт iowait: м.б. это RAID1 (4 зеркала) так
> себя ведёт?
Так бы сразу и сказал ... ;)

Отрывай ему data=ordered ...
tune2fs -o journal_data_writeback /dev/????
Перемонтируй, чтоб применилось.
Потом оторви bitmap...

А перед ем  подумай, к чему это все приведет...
Потому как если шо, то я не виноват...

Но у меня LA упало с 2,7 до 0,3 ...

-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[Vladimir Karpinsky]

28.07.2012 15:37, Dmitriy Kruglikov пишет:
> 28 июля 2012 г., 14:32 пользователь Vladimir Karpinsky
> <vkarpinsky@mail.ru> написал:
>> Там 3 одинаковых процесса. Насчёт iowait: м.б. это RAID1 (4 зеркала) так
>> себя ведёт?
> Так бы сразу и сказал ... ;)
>
> Отрывай ему data=ordered ...
> tune2fs -o journal_data_writeback /dev/????
> Перемонтируй, чтоб применилось.
> Потом оторви bitmap...
>
> А перед ем  подумай, к чему это все приведет...
> Потому как если шо, то я не виноват...
>
> Но у меня LA упало с 2,7 до 0,3 ...

Можно по-подробнее? А то, я часть слов, приведённых выше, знаю, но не все ;-).

Чем грозит?

Отрывать всем массивам или только тому, на котором это всё происходит (/home)?

Перед tune2fs надо отмонтировать?

Нужен тотальный бэкап перед tune2fs или эта операция не влияет на данные 
раздела?

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Dmitriy Kruglikov]

28 июля 2012 г., 14:47 пользователь Vladimir Karpinsky
<vkarpinsky@mail.ru> написал:

> Можно по-подробнее? А то, я часть слов, приведённых выше, знаю, но не все
> ;-).
Можно но я предпочитаю рекомендовать вам детально разобраться с
незнакомыми словами.

> Чем грозит?
От "ни чем" до "полной потери" данных...
В зависимости от квалификации. Потому и читать от и до...

> Отрывать всем массивам или только тому, на котором это всё происходит
> (/home)?
Для начала, только тот, который вызыывает проблемя.
Потом остальный...
Потом, пройтись по району и ...
Ну, вы меня поняли...

> Перед tune2fs надо отмонтировать?
Даже если это и не нужно, я предпочел отмонтировать.

> Нужен тотальный бэкап перед tune2fs или эта операция не влияет на данные
> раздела?
Даже если и не влияет, бэкап будет хорошей идеей...

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

-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[Vladimir Karpinsky]

Почитал, подумал...

28.07.2012 15:47, Vladimir Karpinsky пишет:
> 28.07.2012 15:37, Dmitriy Kruglikov пишет:
>> 28 июля 2012 г., 14:32 пользователь Vladimir Karpinsky
>> <vkarpinsky@mail.ru> написал:
>>> Там 3 одинаковых процесса. Насчёт iowait: м.б. это RAID1 (4 зеркала) так
>>> себя ведёт?
>> Так бы сразу и сказал ... ;)
>>
>> Отрывай ему data=ordered ...
>> tune2fs -o journal_data_writeback /dev/????
>> Перемонтируй, чтоб применилось.

Сделал для /home, собрал все данные (до и после) на этом разделе/массиве 
(до этого источник был на другом), перемонтировал, но пока результата нет, 
--- скорость таже и iowait тот же...

>> Потом оторви bitmap...

Это я так понимаю, уже параметр mdadm? Правильно ли я понимаю, что надо 
массив пересоздавать?

>> А перед ем  подумай, к чему это все приведет...
>> Потому как если шо, то я не виноват...
>>
>> Но у меня LA упало с 2,7 до 0,3 ...

la тоже высокий остался

>
> Можно по-подробнее? А то, я часть слов, приведённых выше, знаю, но не все ;-).
>
> Чем грозит?
>
> Отрывать всем массивам или только тому, на котором это всё происходит (/home)?
>
> Перед tune2fs надо отмонтировать?
>
> Нужен тотальный бэкап перед tune2fs или эта операция не влияет на данные
> раздела?
>

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Vladimir Karpinsky]

28.07.2012 17:02, Dmitriy Kruglikov пишет:
> Можно но я предпочитаю рекомендовать вам детально разобраться с
> незнакомыми словами.

Я безусловно этим сразу занялся и занимаюсь.

Нашёл:
mdadm --grow --bitmap=none /dev/md0

и

mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md0

Но до конца не могу понять насколько это возможно и безопасно делать на 
работающем массиве.

> Даже если и не влияет, бэкап будет хорошей идеей...

Это понятно, но пока всё работает в тестовом режиме, если шансы на падение 
не столь велики, то не хочется потерять время на копирование больших 
объёмов, если всё грохнется, то потребуется только время на восстановление.


-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Vladimir Karpinsky]

Тут похоже сложнее: в программе есть O_SYNC (ещё с SUNов), на который, 
видимо, раньше многие плевали (в т.ч. ди сих пор плюёт windows), а сейчас 
видимо пытаются обрабатывать. А это, как раз LA, плюс SoftRAID, плюс 
журнал... Сейчас будем делать версию без о_синка, а дальше, если будет 
эффект, думать о том, насколько без него нельзя жить.

28.07.2012 17:02, Dmitriy Kruglikov пишет:
> Можно но я предпочитаю рекомендовать вам детально разобраться с
> незнакомыми словами.

Пока изыскания закрываю. Огромное спасибо, --- я с Вашей помощью несколько 
новых слов узнал ;-)!

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Vladimir Karpinsky" <vkarpinsky@mail.ru>
> Кому: community@lists.altlinux.org
> Отправленные: Суббота, 28 Июль 2012 г 22:04:00
> Тема: Re: [Comm] Производительность
> 
> Почитал, подумал...
> 
> 28.07.2012 15:47, Vladimir Karpinsky пишет:
> > 28.07.2012 15:37, Dmitriy Kruglikov пишет:
> >> 28 июля 2012 г., 14:32 пользователь Vladimir Karpinsky
> >> <vkarpinsky@mail.ru> написал:
> >>> Там 3 одинаковых процесса. Насчёт iowait: м.б. это RAID1 (4
> >>> зеркала) так
> >>> себя ведёт?
> >> Так бы сразу и сказал ... ;)
> >>
> >> Отрывай ему data=ordered ...
> >> tune2fs -o journal_data_writeback /dev/????
> >> Перемонтируй, чтоб применилось.
> 
> Сделал для /home, собрал все данные (до и после) на этом
> разделе/массиве
> (до этого источник был на другом), перемонтировал, но пока результата
> нет,
> --- скорость таже и iowait тот же...
> 
> >> Потом оторви bitmap...
> 
> Это я так понимаю, уже параметр mdadm? Правильно ли я понимаю, что
> надо
> массив пересоздавать?
> 
> >> А перед ем  подумай, к чему это все приведет...
> >> Потому как если шо, то я не виноват...
> >>
> >> Но у меня LA упало с 2,7 до 0,3 ...
> 
> la тоже высокий остался

Посмотрите что показывает в:

/sys/block/[имя_жесткого_диска(sda, bla-bla-vla)]/queue

?

если нечто:

noop [cfq]

То можно попробовать на все диски, входящие в массивы:

echo "noop" > /sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue

Планировщик cfq при активной записи больших объемов данных у меня регулярно
окукливает системы.

Re: [Comm] Производительность

[Anton Gorlov]

29.07.2012 4:36, Alexei Takaseev пишет:
> echo "noop" >/sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue
>
> Планировщик cfq при активной записи больших объемов данных у меня регулярно
> окукливает системы.
+1. Использую или noop или anticipatory, на аппаратных рейдах deadline

Re: [Comm] Производительность

[Michael Shigorin]

On Mon, Jul 30, 2012 at 09:40:21AM +0400, Anton Gorlov wrote:
> >echo "noop" >/sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue

Всё же /sys/block/sd?/queue/scheduler

> >Планировщик cfq при активной записи больших объемов данных у
> >меня регулярно окукливает системы.
> +1. Использую или noop или anticipatory, на аппаратных рейдах deadline

Остановился на deadline и для серверов с HDD/CF, и для ноута с SSD.
noop оказался для SSD неприятней на ощупь, он скорее пригоден для
виртуализованного стораджа или хорошего RAID-контроллера IMHO...

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

Re: [Comm] Производительность

[Dmitriy Kruglikov]

30 июля 2012 г., 9:06 пользователь Michael Shigorin <mike@osdn.org.ua> написал:

> Всё же /sys/block/sd?/queue/scheduler

Взгрустнулось... Поигрался...

Имеем raid1 ...
/dev/md5 on /opt type ext4
(rw,nosuid,nodev,relatime,barrier=0,nodelalloc,data=writeback)

# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
# cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Тестовое задание:
# dd if=/dev/zero bs=1M count=5000 of=./zero.dd
Для cfq
LA ~ 3,2
5242880000 bytes (5.2 GB) copied, 55.0603 s, 95.2 MB/s

Для noop
LA ~ 6,02
5242880000 bytes (5.2 GB) copied, 62.1367 s, 84.4 MB/s

Для deadline
LA ~ 3,7
5242880000 bytes (5.2 GB) copied, 46.8136 s, 112 MB/s

Для anticipatory
LA ~ 2,2
5242880000 bytes (5.2 GB) copied, 47.8624 s, 110 MB/s

До отрывания bimap  и при data=ordered
тестовое задание выполнялось со скоростью ~ 43 MB/s при LA ~ 10-12 ...

Может быть кто-то где-то как-то почерпнет для себя "О пользе
правильных defaults"...
;)

-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[Michael Shigorin]

On Sat, Jul 28, 2012 at 02:40:16PM +0400, Vladimir Karpinsky wrote:
> Ядро 3.0.36.

Попробуйте un-def-3.4.6 на всякий, а ещё хорошо бы посмотреть
strace по этому процессу здесь и на centos -- возможно, станет
заметней.  Только -o log, чтоб не тормозить на выводе.

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

Re: [Comm] Производительность

[Michael Shigorin]

On Sat, Jul 28, 2012 at 04:02:33PM +0300, Dmitriy Kruglikov wrote:
> > Можно по-подробнее? А то, я часть слов, приведённых выше,
> > знаю, но не все ;-).
> Можно но я предпочитаю рекомендовать вам детально разобраться
> с незнакомыми словами.

Довольно трудно отрывать write intent bitmap,
если grep bitmap /proc/mdstat пуст.

После отрывания O_SYNC при всё-таки слишком высокой нагрузке
я бы пробовал писать или на ext4, или на xfs.  Также стоит
проверить, что используемые диски -- не 4k-секторные либо
соответственно выровнены (http://www.altlinux.org/BigSector).
И ещё https://bugzilla.altlinux.org/27399

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

Re: [Comm] Производительность

[Dmitriy Kruglikov]

30 июля 2012 г., 9:49 пользователь Michael Shigorin написал:

> Довольно трудно отрывать write intent bitmap,
> если grep bitmap /proc/mdstat пуст.
Ну дык.... Это ...
Чтобы выкинуть что-нибудь ненужное нужно сперва купить что-нибудь ненужное ...
Я как прочитал в консоли, что "опаньки", сразу вписал ordered, а потом
установил writeback

> И ещё https://bugzilla.altlinux.org/27399
Да, ядро там обновить давно пора...



-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[Vladimir Karpinsky]

Здравствуйте!

30.07.2012 10:49, Michael Shigorin пишет:
> On Sat, Jul 28, 2012 at 04:02:33PM +0300, Dmitriy Kruglikov wrote:
>>> Можно по-подробнее? А то, я часть слов, приведённых выше,
>>> знаю, но не все ;-).
>> Можно но я предпочитаю рекомендовать вам детально разобраться
>> с незнакомыми словами.
>
> Довольно трудно отрывать write intent bitmap,
> если grep bitmap /proc/mdstat пуст.

Правильно ли я понимаю, что после tune2fs -o journal_data_writeback /dev/????

Информация в журнал записывается после завершения записи данных, а не до? У 
меня сейчас стало:
Default mount options:    journal_data_writeback
Можно попытаться вернуться к дефолтному состоянию, но не знаю как...

> После отрывания O_SYNC при всё-таки слишком высокой нагрузке
> я бы пробовал писать или на ext4, или на xfs.  Также стоит
> проверить, что используемые диски -- не 4k-секторные либо
> соответственно выровнены (http://www.altlinux.org/BigSector).
> И ещё https://bugzilla.altlinux.org/27399

Это я проверял. Нагрузка там не очень большая, просто стояла задача 
гарантировать запись _информации о_ данных в петле после записи данных, в 
противном случае, отказаться от всей операции. Другое дело, что на SUNах 
это работало, а в Linux толком нет, то ли не так обрабатывалось, то ли 
программисты не так использовали это для Linux, во всяком случае, при 
каких-то электроавариях петля всё равно часто оказывалась битой. Сейчас 
после исключения O_SYNC всё стало бегать на порядки быстрее, LA упало до 
0.2. А дальше будем тестировать...

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[adobrovolskii]

2012/7/30 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, Jul 30, 2012 at 09:40:21AM +0400, Anton Gorlov wrote:
>> >echo "noop" >/sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue
>
> Всё же /sys/block/sd?/queue/scheduler
>
А какой формат этого файла? Где читать?
Что значит:
cat /sys/block/sda/queue/scheduler
noop [cfq]
? Какой планировшик используется?

-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] Производительность

[Michael Shigorin]

On Mon, Jul 30, 2012 at 02:24:40PM +0300, adobrovolskii wrote:
> >> >echo "noop" >/sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue
> > Всё же /sys/block/sd?/queue/scheduler
> А какой формат этого файла? Где читать?

На чтение -- список доступных планировщиков и текущий выделен
квадратными скобками; на запись -- строка с именем нужного.

> Что значит:
> cat /sys/block/sda/queue/scheduler
> noop [cfq]
> ? Какой планировшик используется?

cfq

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

Re: [Comm] Производительность

[Dmitriy Kruglikov]

30 июля 2012 г., 14:24 пользователь adobrovolskii  написал:

> Что значит:
> cat /sys/block/sda/queue/scheduler
> noop [cfq]
> ? Какой планировшик используется?

Который [тут]

-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Производительность

[adobrovolskii]

2012/7/30 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, Jul 30, 2012 at 02:24:40PM +0300, adobrovolskii wrote:
>> >> >echo "noop" >/sys/block/[имя_жесткого_диска(sda, bla-bla-bla)]/queue
>> > Всё же /sys/block/sd?/queue/scheduler
>> А какой формат этого файла? Где читать?
>
> На чтение -- список доступных планировщиков и текущий выделен
> квадратными скобками; на запись -- строка с именем нужного.
>
На чтение и на запись можно использовать разные планировщики?!
Как это должно выглядеть в файле?
>> Что значит:
>> cat /sys/block/sda/queue/scheduler
>> noop [cfq]
>> ? Какой планировшик используется?
>
> cfq
>
спасибо, понял.
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] Производительность

[Michael Shigorin]

On Mon, Jul 30, 2012 at 12:06:54PM +0400, Vladimir Karpinsky wrote:
> Другое дело, что на SUNах это работало, а в Linux толком нет,

И там, и там SCSI?

> во всяком случае, при каких-то электроавариях петля всё равно
> часто оказывалась битой.

Эээ... так UPS и всех делов, или чего-то не понимаю?

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

Re: [Comm] Производительность

[Vladimir Karpinsky]

30.07.2012 17:18, Michael Shigorin пишет:
> On Mon, Jul 30, 2012 at 12:06:54PM +0400, Vladimir Karpinsky wrote:
>> Другое дело, что на SUNах это работало, а в Linux толком нет,
>
> И там, и там SCSI?

SUNов раньше было сравнительно много разных, скорее всего везде были SCSI, 
там м.б. даже контроллер это отрабатывал. А здесь SATA + SoftRAID.

>> во всяком случае, при каких-то электроавариях петля всё равно
>> часто оказывалась битой.
>
> Эээ... так UPS и всех делов, или чего-то не понимаю?

Проблема была понять в чём тормоза, пока тормозило на компьютере 7-летней 
давности, списывали на дряхлость железа, а, когда появился компьютер 
достаточно современный --- пришлось разбираться. Кроме того, ноги у этого 
софта растут из прошлого века, в некоторые закутки люди уже десятилетия не 
заглядывали...

Теперь да: UPS в работу, а O_SYNC --- в сторону, во всяком случае для ПК.

-- 
	С уважением,
		Владимир.

Re: [Comm] Производительность

[Dmitry Chistikov]

adobrovolskii, Jul. 30, 2012, 15:14 +0300:
> 2012/7/30 Michael Shigorin <mike@osdn.org.ua>:
> > На чтение -- список доступных планировщиков и текущий выделен
> > квадратными скобками; на запись -- строка с именем нужного.
> >
> На чтение и на запись можно использовать разные планировщики?!

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

-- 
Дмитрий Чистиков

Re: [Comm] Производительность

[adobrovolskii]

2012/7/30 Dmitry Chistikov <dd1email@gmail.com>:
> adobrovolskii, Jul. 30, 2012, 15:14 +0300:
>> 2012/7/30 Michael Shigorin <mike@osdn.org.ua>:
>> > На чтение -- список доступных планировщиков и текущий выделен
>> > квадратными скобками; на запись -- строка с именем нужного.
>> >
>> На чтение и на запись можно использовать разные планировщики?!
>
> Переформулирую: если пытаться из этого файла читать, то будет прочитан
> список; если в него попытаться записать, то это будет интерпретировано
> как приказ сменить планировщик.
А... Понял.
:)
-- 
Regards,
Andrii Dobrovol`s`kyj