Подскажите, это не имитация ли работы с памятью в FreeBSD?

Ты бы еще про OS/2 вспомнил:-) Там тоже что то было вроде ленивого свопа :-))

Ленивый своп это несколько другое

это когда пишешь на диск кучу старых страниц чтоб потом их
было можно выбросить без зазрения совести. Здесь же пишутся
не только private но и public странички из файлового кэша.

Экономия на компиляции кернела - это круто ;)

Компиляция кернела была приведена как один из примеров нагрузки на диск/память/проц

Да ну, на современных быстрых дисках это почти не актуально. Я давно
не видел, чтобы сброс буфферов как-то заметно чего-то тормозил.
По краней мере визуально это не заметно.

Уверяю Вас - это весьма актуально. Возможно у Вас небыло так много буферов.

эх, народ, народ... вам не приходилось работать на писюке под линухом на котором крутится парочка батчовых заданий, причём 30% времени каждого из которых занимают дисковые операции - обработка данных эксперимента физики высоких энергий (суммарный объём данных- сотни гигабайт :(, это маленький эксперимент) ? Уверяю вас, через час от ваших ругательств покраснеют стены, а через день работы в таком окружении вы будете готовы казнить автора линуха всеми известными вам способами. Я не любитель виндозы, жисть начинал под DEC UNIX, но до серьёзных систем линуху ещё расти и расти. И никакие примочки вроде сабжа здесь не помогут :(. (без preemptible kernel в вышеописанном случае по-моему вообще не обойтись)

Будете смеяться, но есть preemptive linux kernel патч. войдет в основное ядро в 2.5 timeframe. Не вижу, правда, чем это поможет. Если диск занят, то хоть в 20 потоков к нему постройся - ничего не отдаст пока не найдет. А в случае RAID/умных SCSI - такая проблема и не должна возникать.

> причём 30% времени каждого из которых занимают дисковые операции

Хех, человек, с дуру можно и хрустальной вазой гвозди забивать.
Это ж очевидно - если приложение IO bound, то нужен SCSI!
И при чем тут линух? В других системах что, где-то лучше получается на IDE дисках?

to anonymous (*) (2001-07-05 22:52:48.0):
И еще. Твои батчовые задания вертелись на ядре 2.2? Тогда попробуй 2.4.
Оно с подобными приложениями работает значительно мягче даже на IDE.

to anonymous: Эх anonymous, если ты ругаешь автора ядра линуха, так ты купи себе Мэинфрэйм, денег на то ты наверное заработал считая такие крутые задачи, а если не заработал считай под ДОСом или Виндовсом-95. А еще лучше перепиши ядро как тебя будет устраивать. Ругать то проще всего.

еще дельная идея для анонимуса с HEP задачей :) типа данные на винте храните в сжатом виде --- за счет проца получите шустрее данные с диска ,)

Наконец то :) У меня стоит магнитооптика, когда на нее пишешь, это дело все очень тормозит, хотя сам девайс довольно быстрый... Если б еще стандартно сделали эту штуку в ядре..

www.freshmeat.net/search/?q=e2compr ? :))) можно foodtechnologist'a думаю потрясти --- он вроде под ней живет :)

а что такое preemptible kernel?

2green: есть два выхода: 1)хорошее железо+плохой софт, 2)плохое железо+хороший софт. Сколько стоят SCSI диски на несколько сотен гигабайт лучше не считать, Россия такого позволить для своих учёных не может :\, хотя выкинуть весьма кругленькую сумму, например, на поднятие "Курска" она может. Знаете сколько получает, для примера, мнс в НИИ по тарифу? Для не знающих сообщаю: 50$ в месяц.

Preemptive (так вроде правильнее) ядро, как я себе представляю, отнимает проц у любого процесса когда он становится нужен более приоритетному процессу, причём его не волнует в user mode или kernel mode (дисковая операция, например) находится текущий процесс. Линух пока этим свойством не обладает, в рез-те набиваемый текст отображается на терминале когда её величество kernel mod'a изволит закончить свою работу, что может весьма раздражать.

Да, пунктик у линуксоидов к винде есть ( anonymous (*) (2001-07-06 06:02:54.0) ), мне честно говоря, смешно (сам под линухом два года сижу), а вот у обывателя ничего кроме отвращения такая агрессия не вызовет (тонкий намёк :). Все системы имеют право на существование, винда для офисных десктопов, домохозяек и геймеров оченно подходит. Я, не знаю к счастью или к сожалению, с ней не работал и не работаю вообще, можно сказать с другой планеты :). А среди интересных мне осей я присматриваюсь к QNX. Прошлой осенью была запущена акция get QNX по бесплатной раздаче бинарников. А сама ось мне нравится из-за кучи вкусностей: микроядерная архитектура (по-моему Линус неоправдано обливает её грязью, устойчивость у неё гораздо выше монолита и пять девяток QNX тому доказательство, а насчёт Mach'a - ктож им доктор), преемптив ядро, реал-тайм, масштабируемость, POSIX-совместимость, GNU-tools, ... читайте сами (начиная с www.qnx.com).

to anonymous (*) (2001-07-06 17:52:41.0)
Ты чего туфту какую-то рассказываешь. Ты определись сначала что тебе нужно.
Серверная производительность для батчовых заданий или десктопная интерактивность
для консоли? Имеешь ли ты понятие о том, что это взаимоподавляющие характеристики?
И что это за нытье про прелести qnx? Ты сначала попробуй тоже самое запустить на qnx,
потом сравнивай. Тебе же дали нормальные советы как сгладить проблему.
Ядро 2.4 ставил? Сравнивал?

Интересно в чём конкретно туфта? В том что линух не preemptive или что QNX микроядерный? Или что ещё 15-20 лет назад на мэйнфрэймах которые по производительности не годились и в подмётки современным писюкам куча народу интерактивно работала без проблем и одновременно пускала кучу батчей? Ну да архитектура и железо мэйнфрэйма не чета писюковым, но мегагерцы совсем не те. А я _никакими_ изменениями приоритетов не могу получить очень даже медленное по процовым меркам время реакции. И не надо про взаимоподавляющие характеристики, не в планировании процового времени дело, а в отсутствии прерываемости операций в кернеле.

> Интересно в чём конкретно туфта? В том что линух не preemptive или что QNX микроядерный?
В том, что ты не пробовал qnx для тех же задач, а заранее уверен в лучшем результате.
А я уверен, что на том же диске и на том же проце с qnx ты не получишь лучшей интерактивности,
чем та, которая есть на linux-2.4. У linux-2.2 она действительно будет несколько хуже.

Mэйнфрэйм с писюком предлагаю не сравнивать.

> И не надо про взаимоподавляющие характеристики, не в планировании процового времени дело,
> а в отсутствии прерываемости операций в кернеле.

Подумай на простым таким фактом: если взять два диска с одной и той же
скоростью вращения, один - SCSI, а другой IDE, то со SCSI интерактивность
будет выше. Так еще раз тогда вопрос: кернел ли виноват в этой разнице?
Дошло?

И я еще в десятый раз повторю: поставь ядро 2.4. Оно работает _очень_ мягко и интерактивно даже на очень интенсивных дисковых операциях.

to anonymous (*) (2001-07-05 22:52:48.0)
Еще одно решение - RT Linux. Микроядро, позволяющее запускать оригинальное ядро Линуха как обчный процесс.

Да поймите вы люди, если прога стоит в ожидании disk i/o никакой RT Linux/QNX/win10000
вам не помогут. Просто напишите это на стенке крупными буквами и изредка поглядывайте,
чтобы не забыть. Если и это не понятно, то представьте утренний час-пик и
1000 человек на автобусной остановке. Подходит один автобус... У вас есть
лишь два крайних варианта между которыми вы можете искать оптимальный путь:

1) набить автобус до отказа. Но тем самым вы замедлите его скорость до предела,
хотя сможете забрать сразу 200 человек.
2) позволить войти минимальному количеству пассажиров, и рассчитывать на более
быстрое возвращение за остальными за счет более высокой скорости.

Без смены/добавления автобусов ни одно решение не позволяет перевезти сразу всех!

Есть еще вариант проложить метро (сравнение со SCSI), но для нашего случая это отпадает
за отсутствием денег у соответствующей организации.

to anonymous (*) (2001-07-08 01:43:02.0): >если _ПРОГА_ стоит в ожидании disk i/o никакой RT Linux/QNX/win10000 вам не помогут Как раз в этом случае помогает даже вынь. Проблема-то в том, что при сбросе на диск "грязных" буферов _ЯДРО_ не отдаёт управление процессам ни при каких обстоятельсвах (если буферов накопилось много - имеем проблему).

Есть даже решение данной пробемы "в лоб" - сбрасывать буфера маленькими порциями. Но тут значительно теряем производительность на обычных задачах (количество лишних переключений ядро-процесс увеличивается).

В RealTime ОС имеем ту же картину: гарантируя время отклика по прерыванию на уровне микросекунд (for Pentium I), они не могут соревноваться с обычными ОС в производительности.

Так что все-таки ты прав: без жертв эту пробему решить нельзя.

to anonymous (*) (2001-07-07 19:03:07.0): запости сюда листинг vmstat, выполненной при тормозухе. А то пустой фантик обсасывать дал, да еще на Линух ругаешься :-(

> Проблема-то в том, что при сбросе на диск "грязных" буферов _ЯДРО_

Нет, не в этом проблема. Понимаешь, не так часто они сбрасываются, чтоб
беспокоиться о них. Проблема именно в борьбе за диск на обычных операциях
чтение/запись инициируемых прикладными программами. К примеру с автобусом:
пусть из тысячи пассажиров можно пометить 20 "внеочередников", посадить
их и сразу отправить. Как быть со следующими 20-ю, подошедшими как-раз
после отправления? Все упирается в физический уровень. Если ядро имеет
гарантированное время отклика одну микросекунду, то смысла в этом ноль,
если учесть, что время срабатывания какого-нибудь реле измеряется уже
в десятках миллисекунд.

> vmstat 1
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  0  0  27052   2196  12540  42176   9   3    22    17   50    66  82   2  16
 0  1  1  27052   1288  12920  42696   0   0     0   162 2586   965   8  16  77
 2  1  1  27052   2284  13064  41540   0   0     8   531 6171  1418  14  53  33
 3  0  0  27052   1284  13852  41748   0   0     0   260 4980  2287  21  23  57
 4  0  0  27052   3072  13376  40440   0   0     0   778 7788  1124  15  61  24
 1  0  0  27052   3064  13392  40332   0   0   182   495 7215  1597  17  50  34
 2  0  1  27292   1748  14752  40520   0 240   259   416 5770   491  43  57   0
 2  0  0  27420   3172  14628  39332   0 128   230   783 8573   411  33  67   0
 4  0  0  27420   1688  16128  39304   0   0   288   388 5768   547  63  38   0
 4  0  0  27420   3076  16056  37976   0   0   225   754 8288   509  43  56   1
 3  0  0  27420   1296  17728  38064   0   0   288   364 5563   483  45  55   0
 5  0  0  27420   3168  17372  36536   0   0   192   748 7880   383  55  45   0
 2  0  2  27420   3168  18096  35784   0   0   320   734 8908   567  47  53   0
 6  0  0  27420   1684  19424  35932   0   0   289   380 5716   560  55  43   2
 4  0  2  27420   3180  18672  35184   0   0   192   714 7660   390  41  59   0
 2  0  0  27612   1880  19608  35728   0 192   274   414 5855   506  44  56   0
 2  0  0  27612   3064  18508  35648   0   0   256   733 8345   540  46  54   0
 2  0  0  27612   1388  19724  36100   0   0   289   356 5503   488  54  46   0
 5  0  0  27612   3140  18736  35332   0   0   192   722 7725   339  51  49   0
 2  0  0  27612   1576  19896  35740   0   0   288   380 5706   569  49  51   0
 7  0  0  27612   3180  18784  35256   0   0   192   748 7958   396  47  53   0
 2  0  0  27612   1792  19676  35744   0   0   289   388 5775   581  59  40   1
 1  0  2  27612   3160  18676  35372   0   0   224   746 8198   486  44  56   0
 2  0  0  27612   1556  19780  35868   0   0   288   380 5701   487  47  53   0
 5  0  2  27832   3108  18896  35436   0 220   192   771 8153   419  32  68   0
 2  0  0  27832   1580  20100  35744   0   0   289   372 5649   550  51  49   0
 1  0  1  27832   3176  19048  35196   0   0   224   738 8081   377  34  66   0
 2  0  0  27832   1528  20276  35636   0   0   288   388 5762   567  42  58   0
 4  0  1  27832   3060  19316  35060   0   0   192   714 7675   412  31  69   0
 3  0  0  27832   1576  20312  35540   0   0   288   358 5539   569  51  49   0
 1  0  0  27832   3064  19288  35064   0   0   225   770 8429   498  37  62   1
 2  0  0  27832   1496  20412  35512   0   0   288   364 5587   535  50  50   0
 5  0  2  27832   3176  19296  34964   0   0   192   778 8213   442  35  65   0
 2  0  0  28020   1976  20100  35536   0 188   273   415 5877   546  35  65   0
 4  0  0  28020   3060  19492  35060   0   0   257   728 8353   463  45  55   0
 2  0  0  28020   1392  20856  35364   0   0   288   359 5545   598  60  40   0
 1  0  1  28020   3168  19660  34768   0   0   192   745 7947   470  43  57   0
 2  0  0  28020   1492  20904  35196   0   0   289   382 5741   537  43  57   0
 4  1  0  28020  11048  20592  26048  20   0   112   358 4131   681  64  30   6
 2  0  0  28020  10392  20612  26716  24   0   173     0 1753   946  89  11   0
 3  0  0  28020  10392  20612  26716   0   0     0     0  370  1008  93   7   0
 3  0  0  28020  10264  20612  26844   0   0    32     0  624   981  91   9   0
 2  0  1  28020  10208  20668  26844   0   0    14     0  338   593  97   1   2

PIII-450/128MB. bIO мало - никаких проблем, велико - можно только
отдыхать (по отношению block input/output можно понять, что работает
архиватор). Расклад такой: сколько достаётся батчу от времени проца
меня не интересует абсолютно, пусть он будет крутиться даже в два и
больше раз дольше при "удобном" времени реакции на клаву и мышь, а
вот весьма ощутимые задержки в интерактивной работе при
"ускоренной" работе батча на оптимизированном под общую
perfomance планировщика ядра линуха, меня не устраивают
абсолютно, и что плохо, исправить это в линухе я не могу (разве что
замочить батч). А 2.4 попробую. Спасибо за внимание и советы умных
людей :).

Не написал самое главное - какое ядро, какой диск (модель, вывод hdparm -tT /dev/hd??).
Лучший твой товарищ - 2.4 + low-latency patch. И еще. dma на диске включено?
unmasqirq, readahead, 32-bit IO и т.д? Не знаю, что там у тебя за такая зверская задача.
Я никогда не видел стопоров у себя даже при одновременном исполнения updatedb (для locate)
и logrotate. В фоне еще несколько ftp-сессий, браузер и куча всего остального.

2anonymous (*) (2001-07-08 18:26:55.0): > Проблема именно в борьбе за диск на обычных операциях чтение/запись инициируемых прикладными программами

Бог с вами, батенька! Каждая операция ввода-вывода проходит через ядро. Проги только передают данные через системые вызовы в буфер ОС. Дальше уже дело с ними имеет только ядро, оно и решает, когда их сбрасывать на диск. Об этой фазе в ядре я и говорю. Читай комментарии в /usr/src/linux/fs/buffer.c

> Если ядро имеет гарантированное время отклика одну микросекунду, то смысла в этом ноль, если учесть, что время срабатывания какого-нибудь реле измеряется уже в десятках миллисекунд.

Читай технич. описание QNX. Гарантированное время реакции (т.е. вызов обработчика прерывания/драйвера относительно самого прерывания) для P-166 - 4,7 мкс. для 386SX - 74,2 мкс (еще раз повторяю - для QNX).

А толку от этого не ноль - на этих осях держится индустрия встраиваемых компьютеров. Там задержка на долю секунды равноценна отказу.

Про время срабатывания _СОВРЕМЕННЫХ_ реле шутку я заценил ;-)

> Читай технич. описание QNX. Гарантированное время реакции
Я таки пытаюсь указать на проблему "самого узкого места", которое и
определяет время реакции системы.

> для P-166 - 4,7 мкс. для 386SX - 74,2 мкс
а время доступа к диску - 8-9 мс...
Так вот товарищ явно знает про микросекунды, но забывает, что у него
стоит нечто, дающее на порядок большую задержку. Линукс сам по себе
может обеспечить latency порядка 2-10 мс, что например более чем достаточно
для большинства мультимедийных приложений.

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

Понял, что сказал?
Только не говори мне, что ты думаешь, что во время поиска дорожки на винте процессор не может передать управление другой задаче.
Собщаю секретную информацию: для таких медленных устройств как винт еще в прошлом веке придумали перефирийные контроллеры ввода-вывода.

> Линукс сам по себе может обеспечить latency порядка 2-10 мс
Все зависит от того, что ты имеешь в виду под latency.

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

Мы говорим о ситуации, когда некая задача очень активно работает с диском на
пределе его возможностей. Так вот, процессор отдается другой задаче. Но вот беда!
Эта задача тоже требует обращения к диску. Пример: в консоли запускаем /bin/ls.
Я про это говорю. Процессор там может быть и на 10% не загружен, в то время как
диск раскаляется до красна от работы.

> Все зависит от того, что ты имеешь в виду под latency.
А то же, что и гарантированное время реакции.

2anonymous (*) (2001-07-09 15:15:17.0):
1. "гарантированное вермя реакции Линуха порядка 2-10 мс" => "Линух является системой Hard Real-Time"! Нонсенс!
Не растраивай меня.
Ты хоть знаешь, каким параметром определяется время реакции?
Если бы знал, такое не сказал.

2. Про ls не надо: набивка текста не работа с диском. (человек именно во время набивки проблемы имел
см. anonymous (*) (2001-07-06 17:52:41.0)
Стоять не падать, от курса не отклоняться!

> "гарантированное вермя реакции Линуха порядка 2-10 мс" => "Линух является системой Hard Real-Time"!
Линукс может (при соответствующей доводке/настройке) являться системой Soft Real-Time ;)
Кроме шуток, этот термин уже начинает приживаться.

> Про ls не надо: набивка текста не работа с диском.
Этот человек вообще ничего конкретного не рассказал. Как партизан на допросе.
Он ничего не сказал про свой диск (что если это noname 600 Mb 1994 года?),
ничего не сказал про ядро, про параметры настройки системы. Я не ясновидящий.
К тому же я сам у себя такого не наблюдаю! Пускаю одновременно lmbench + bonnie
и набиваю текст. Нету тормозов! Что я могу еще сказать?

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

И напоследок:
http://rdimitr.chat.ru/rtlinux/short.htm
In practice, the RT-Linux approach has proven to be very successful. Worst case interrupt latency on a 486/33Mhz PC measures well under 30 microseconds, close to the hardware limit...
In such cases, the _I/O buffering_ and aggregation performed by Linux provides a high level of average case performance while the real-time task meets strict worst-case limited deadlines.

На макроядре это практически недостижимо.

2anonymous (*) (2001-07-09 20:16:23.0): IBM-DJNA-372200, 21557MB w/1966kB Cache, CHS=2748/255/63. Попробовал 32-bit I/O и DMA включить - проблема по большей части устраняется, теперь буду ждать проблем с файловой системой, как она взбрыкивает после таких разгонов я уже давно слышал. Но проблемы с отсутствием прерываемости сисколов в линухе всё равно остаются, тут NFS работает на десяток разнесённых компов, как с полноценным IP адресом, так и с локальным, причём name server тоже неблизко (только не спрашивайте почему всё так плохо и у кого руки из задницы растут, что имеем - то храним), в результате NFS (надо сказать не в расслабленной моде работающая) периодически поругивается, но когда она затыкается, начинается полный ступор, вешается всё. Отдельные личности начинают метать икру и искать виноватого. Я понимаю, что в preemptive kernel драйверы всё равно имеют конечное число точек прерывания, но в линухе их пока совсем нет. А в 2.5 кстати драйверы кто-то должен переписать, чтобы реализовать эту возможность, и непонятно есть ли желающие и могущие это сделать.

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

Для твоего винта 32бит+ДМА штатный режим работы. Проблемы с файловой системой при установке ДМА бываю только на старых матерях с винтами не поддерживающими UDMA.

Эх, а говорил что о QNX думать начал. Всегда дешевле разобраться с тем, что есть, чем иметь проблемы с новым. Ученые, где ваш консерватизм!

> Попробовал 32-bit I/O и DMA включить - проблема по большей части устраняется,

Да, братец, как у вас все запущено. Тут народ голову ломает, а им лень man hdparm почитать.
Все отлично работает с dma. Бывают конечно патологические случаи. Но что ж теперь
мучаться и перестраховываться? В инит-скриптах прописывай смело примерно
такую строчку:

/usr/sbin/hdparm -d1 -a8 -m16 -c3 -u1 -k1 /dev/hda (повтори для каждого диска)

> Но проблемы с отсутствием прерываемости сисколов в линухе всё равно остаются,

В 2.4 многие из этих проблем устранены. Поставь и ты будешь приятно удивлен.

2anonymous (*) (2001-07-10 01:10:15.0): Почитать не лень, лень быть кошкой на которой новое обкатывается (попробовал тут иксы 4.1.0 поставить, появились глюки со старым софтом - PAW стал рисовать не так как надо, откатился на 3.3), лень иметь проблемы с "усовершенствованиями" (при вышеописанных объёмах данных, забэкапить возможно далеко не всё, а потеряв восстанавливаемое долгими днями работы я получу "большое спасибо" и от себя и от других). А QNX всёж-таки делалась профи, а не студентом.

2SeRGi (*) (2001-07-10 00:12:46.0): консерватизм нужен когда всё работает как надо и без излишеств.

В обчем это уже брюзжание, спасибО ещё раз.