форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от opennews on 21-Окт-11, 18:02
Кей Сайверс (Kay Sievers (http://linuxplumbersconf.org/2011/ocw/users/33)), Леннарт Поттеринг (Lennart Poettering (http://linuxplumbersconf.org/2011/ocw/users/729)) и Харальд Хойер (Harald Hoyer (http://linuxplumbersconf.org/2011/ocw/users/51)) опубликовали (https://lkml.org/lkml/2011/10/20/275) обновлённый вариант списка возможностей, которых не хватает в ядре Linux по мнению системных программистов, занимающихся разработкой низкоуровневых компонентов для Linux-систем. По сравнению с первым вариантом (http://www.opennet.me/opennews/art.shtml?num=31977) в новом списке добавлены следующие пожелания: -  Добавление в tmpfs поддержки дисковых квот для защиты от переполнения /tmp, /dev/shm, /run/user/$USER отдельным пользователем; -  Добавление корректной поддержки fallocate() для tmpfs для предварительного резервирования места под создаваемые файлы; -  В механизм нотификации fanotify предлагается добавить поддержку генерации событий при переименовании файла, создание безопасно... URL: Новость: http://www.opennet.me/opennews/art.shtml?num=32104
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

3. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от AlexAT (ok) on 21-Окт-11, 18:24
>>> Добавление в tmpfs поддержки дисковых квот для защиты от переполнения /tmp, /dev/shm, /run/user/$USER отдельным пользователем. Да. >>> Использование 64-разрядных PID-идентификаторов по умолчанию. Да! >>> Вариант файловой системы в стиле unionfs или возможность слияния нескольких точек монтирования (union mount). ДА!!! Остальное под вопросом. В частности "управление подкачкой" и "уведомление о завершении любого процесса" - потенциальные дыры.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от gfh (??) on 21-Окт-11, 19:34
	mhddfs ?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	17. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от СуперАноним on 21-Окт-11, 21:54
	>>> Использование 64-разрядных PID-идентификаторов по умолчанию. >Да! Нахрена? Неужели на одной машине может быть одновременно более 4 млрд. процессов? Даже на кластере трудно представить столько.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	19. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от AlexAT (ok) on 21-Окт-11, 21:57
	>>>> Использование 64-разрядных PID-идентификаторов по умолчанию. >>Да! > Нахрена? Неужели на одной машине может быть одновременно более 4 млрд. процессов? > Даже на кластере трудно представить столько. Нет, но неповторяемость идентификаторов при частой смене тысяч процессов типа pppd очень удобна.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	13. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от gegMOPO4 (ok) on 21-Окт-11, 20:55
	Наверняка для этого понадобятся особые права, так что нормально.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от Аноним (??) on 21-Окт-11, 20:04
>Уведомление, когда завершается произвольный процесс, не только дочерний Моя мечта - утилита killwait, которая бы не просто отправляла сигнал процессу, но и дожидалась его завершения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от gegMOPO4 (ok) on 21-Окт-11, 20:59
	...и контрольный выстрел в голову.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	15. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 21-Окт-11, 21:48
	Да, возможность отправить сигнала 9 по таймауту должна быть обязательной фичей.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Новая редакция списка возможностей, которых не хватает в ядр..."	–2 +/–
	Сообщение от Аноним (??) on 21-Окт-11, 21:49
	>Моя мечта - утилита killwait, которая бы не просто отправляла сигнал процессу, но и дожидалась его завершения. #!/bin/bash #killwait kill -9 $1 sleep 1
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	18. "Новая редакция списка возможностей, которых не хватает в ядр..."	+2 +/–
	Сообщение от Аноним (??) on 21-Окт-11, 21:55
	> -9 > sleep 1 не годится.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от gegMOPO4 (ok) on 21-Окт-11, 23:39
	Может попробовать помониторить /proc?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	25. "Новая редакция списка возможностей, которых не хватает в ядр..."	+2 +/–
	Сообщение от Аноним (??) on 22-Окт-11, 00:10
	> Может попробовать помониторить /proc? Может просто стоит признать, что >Уведомление, когда завершается произвольный процесс, не только дочерний. нужная штука?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	23. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 21-Окт-11, 23:57
	kill $1 while kill -0 $1; do sleep 1; done ?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	24. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 22-Окт-11, 00:06
	Примерно такие костыли и использую. Но хотелось бы нормальный способ.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	32. "Новая редакция списка возможностей, которых не хватает в ядр..."	–3 +/–
	Сообщение от Аноним (??) on 22-Окт-11, 14:45
	> #!/bin/bash > #killwait > kill -9 $1 > sleep 1 > > kill $1 > while kill -0 $1; do sleep 1; done > ? Некотрые видимо не понимают разницы между ожиданием таймаута и ожиданием событий. Типа "и так сойдет", "работает же". К сожалению в Linux все больше и больше лоббируются интересы быдлокодеров. Хорошо, что я несколько лет назад собрался с духом и перешел на BSD-системы. Тогда еще были кое-какие проблемы в BSD с поддержкой десктопных решений (сервера там испокон веку были лучше). Сейчас BSD-системы и на десктопах вполне догнали, а вот реализация большинства вещей в BSD на порядки качественней и придерживается философии UNIX. Взять хотя бы способ передачи параметров ядру при вызове функций API. Все нормальные юниксы передают их через стек. И только в Linux почему-то решили подражать Виндам и передавать параметры через регистры. Заставляя приложение все время сохранять и восстанавливать регистры и терять кучу циклов на это, и увеличивая вероятность возникновения ошибок. Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	35. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним0 on 23-Окт-11, 02:10
	боюсь плюсануть, т.к много текста про бсд, совсем неуместного. а вот то что сигналы надо обрабатывать, а не херней страдать с килами и слипами (которые выглядят крайне глупо) хочу подчеркнуть.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	41. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 06:00
	Все там уместно. Тема как озаглавлена? Список возможностей, которых не хватает Линуксу. Вот и было сказано, чего ему не хватает. Ну и что в нем неправильно - сюда же.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от AlexAT (ok) on 23-Окт-11, 14:09
	>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти. >>> Заставляя приложение все время сохранять и восстанавливать регистры и терять кучу циклов на это Зачем? Компилятор настолько туп, что не может оптимизировать доступ к регистрам? >>> и увеличивая вероятность возникновения ошибок. Можно пояснить, чем разница в расположении данных "увеличивает вероятность"? >>> Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен? Есть хитрость - в ряде случаев можно ничего не сохранять.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	44. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от Аноним (??) on 23-Окт-11, 17:23
	>>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то > > Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти. Вы видимо не знаете более достойного использования регистров, пусть даже если регистров большое количество, пусть даже целые регистровые файлы, - кроме как забивание их параметрами процедур. Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других структур данных в современных программах. Вторая подсказка - учитывая вами же высказанное соотношение скорости доступа к регистрам и к памяти - если вас волнует быстродействие, следует посчитывать все вычисления в программе, а не только вызовы процедур. >>>> Заставляя приложение все время сохранять и восстанавливать регистры и терять кучу циклов на это > Зачем? Компилятор настолько туп, что не может оптимизировать доступ к регистрам? Конечно он это оптимизирует, только эта оптимизация в большинстве случаев будет не в пользу процедурных параметров. А DOS^W Linux просто вынуждает забивать ими регистры при системных вызовах. >>>> и увеличивая вероятность возникновения ошибок. > Можно пояснить, чем разница в расположении данных "увеличивает вероятность"? Если вы сами не отлаживали ассемблерный код, полагаетесь исключительно на генераторы и оптимизаторы, если вы занимаетесь только прикладным программированием - для вас разницы нет. А вот для тех, кто занимается разработкой компиляторов и прочих инструментов, которые вы же потом и используете, - для них разница есть. И эта разница как раз и влияет на качество тех инструментов, которые вам достаются, в том числе тех же оптимизаторов и генераторов. >>>> Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен? > Есть хитрость - в ряде случаев можно ничего не сохранять. Если уж речь зашла именно о современных процессорах, то вы видимо не знаете об аналогичных "хитростях" при работе со стеком. И наконец, не забывайте, что речь шла именно о вызовах в ядро. Т.е. на той стороне вы уже имеете оптимизированный код, к которому ваш любимый оптимизатор доступа не имеет. Кроме того, учтите особенности оптимизации ядра. Ах, ну да, у вас же DOS^W Linux, с его особенностями оптимизации. Ну и напоследок, ассемблерный код с передачей параметров через стек - более нагляден, и его легче отлаживать. Хотя конечно если вы считаете, что чем более код запутан, тем круче, для вас наверное это тоже не аргумент.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	45. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от AlexAT (ok) on 23-Окт-11, 18:40
	> Вы видимо не знаете более достойного использования регистров В момент вызова ядра более достойного использования им всё равно нет - все придется сохранять. Суть проста: процедуры в ядре для работы используют что? Регистры! Поэтому хоть так, хоть эдак - а сохранять их перед вызовом придется. Т.е. раз так и так сохранять - зачем делать двойную работу? Пусть софт (к которому имеет доступ оптимизатор) сохраняет только нужные регистры. Вполне грамотный подход. В x86_64, кстати, ядро разрушает не все регистры. > Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других > структур данных в современных программах. Учел. "Структуры данных" на регистры не размещаются, поэтому мимо тазика. А поинтеры можно и перезагрузить. > Вторая подсказка - учитывая вами же высказанное соотношение скорости доступа к регистрам и к памяти - если вас волнует быстродействие, следует посчитывать все > вычисления в программе, а не только вызовы процедур. Балалайку о неоптимальности регистровых вызовов завели вы. Я вам указал на то, что регистровые вызовы оптимальнее стековых, если возможны. Причем во всех ипостасях. По сравнению даже с INT/SYSCALL вся эта чехарда с регистрами - мелочь. > Если уж речь зашла именно о современных процессорах, то вы видимо не > знаете об аналогичных "хитростях" при работе со стеком. Примеры в студию :) > Т.е. на той стороне вы уже имеете оптимизированный код, к которому > ваш любимый оптимизатор доступа не имеет. В данном случае поведение "той стороны" абсолютно не критично. Оптимизировать надо сохранение регистров на стороне caller, и все оптимизаторы это умеют. > Ну и напоследок, ассемблерный код с передачей параметров через стек - более > нагляден, и его легче отлаживать. Дело привычки, не более. А код, генерируемый современными компиляторами, отлаживать трудно хоть так, хоть эдак. Более того (открою страшную тайну) - GCC в ряде случаев может использовать регистровые вызовы для оптимизации.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	52. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от Аноним (??) on 24-Окт-11, 08:36
	(Я переставил некоторые ваши абзацы местами при цитировании, сгруппировав их по смыслу, чтобы мне было удобнее отвечать. Считаю, что смысла я при этом не исказил. Если что исходный текст выше.) > Балалайку о неоптимальности регистровых вызовов завели вы. Я помню, о чем я говорил. В быдлокодерских традициях принято отождествлять оптимизацию и скорость. (Я не утверждаю, что вы непременно быдлокодер, я вашего кода не видел. Однако чувствуется влияние на вас той среды, для которой создавались ДОС и всякие Винды.) Так вот, оптимизация бывает разной. По скорости, по надежности, по простоте, по масштабируемости, по чистоте архитектуры, по удобству проектирования, и много по каким параметрам еще. А также в оптимизации значение имеет суммарный конечный результат, а если одни параметры оптимизируются в ущерб других - зачем такая оптимизация нужна. В нормальных Юниксах принято избегать прежевременной отимизации (по скорости). А также знаменитый принцип KISS. Тем не менее, с быстродействием стековых вызовов в ядро там все в порядке (см. далее). > В момент вызова ядра более достойного использования им всё равно нет - все придется сохранять. > > Суть проста: процедуры в ядре для работы используют что? Регистры! Поэтому хоть так, хоть эдак - а сохранять их перед вызовом придется. Т.е. раз так и так сохранять - зачем делать двойную работу? > > В данном случае поведение "той стороны" абсолютно не критично. Оптимизировать надо сохранение регистров на стороне caller, и все оптимизаторы это умеют. Вот в этом месте вы и попались. Я не зря повторил, что речь идет про вызовы именно в ядро, но вы все проинтерпретировали с точностью до наоборот. Видите ли, в нормальных ОСях (и даже не только в Юниксах) принято доверять ядру, и не доверять прикладному коду. А в DOSовском наследии принято до упора выжимать быстродействие прикладного кода пусть даже в ущерб надежности ядра. Так вот, в нормальных ОСях ядро в любом случае будет сохранять регистры, независимо, сохраняет их caller или нет. И именно в случае вызовов в ядро задачу сохранения регистров оптимальным образом можно смело доверить ядру (на то оно и ядро). И ядро обычно оптимизируется все равно гораздо более изощренно, чем прикладной код. Поэтому стековая передача параметров здесь явно выигрывает. А двойная работа как раз у вас и возникает - когда вы дважды сохраняете одни и те же регистры, сначала в caller, а потом в ядре. Просто вы ничего этого не знаете. Хотя наверное в вашем DOS/Linux ядру действительно не следует так доверять, в него там пихают все что ни попадя. Не знаю. Благо что я от Линукса в свое время ушел на БСД-системы. > Я вам указал на то, что регистровые вызовы оптимальнее стековых, если возможны. Причем во всех ипостасях. > По сравнению даже с INT/SYSCALL вся эта чехарда с регистрами - мелочь. Указывать и просто заявлять - это одно, а знать - это совсем другое. > Пусть софт (к которому имеет доступ оптимизатор) сохраняет только нужные регистры. Вполне грамотный подход. В x86_64, кстати, ядро разрушает не все регистры. Здесь вы только подтверждаете мои слова. Передача параметров через регисры резко увеличивает количество регистров, подлежащих сохранению. А ядро само контролирует, какие регистры нужно сохранять. На то оно и ядро (см. выше). >> Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других >> структур данных в современных программах. > Учел. "Структуры данных" на регистры не размещаются, поэтому мимо тазика. А поинтеры можно и перезагрузить. Само собой речь шла об указателях на структуры. Вот и считайте, сколько раз вы будете переписывать эти указатели, значения которых не меняются, даже если меняются данные самих структур. И учтите сказанное выше, когда не известно, сколько регистров будет использовано в каждом вызове в ядро, и что нормальное ядро оптимально сохранит только нужные регистры. И откуда вы будете эти регисры восстанавливать. Хватит ли вам для этого объема ваших "хитростей" или все таки придется использовать память. Учтите также в современных программах количество глобальных структур (которые используются для всякого там менеджмента памяти и сборщиков мусора, а также для других задач). >> Если уж речь зашла именно о современных процессорах, то вы видимо не >> знаете об аналогичных "хитростях" при работе со стеком. > > Примеры в студию :) Ну вы начали говорить о "хитростях", вот вы первый и приведите примеры в студию. Только смотрите снова не попадитесь. "Хитрости" с регистрами в современных процах безусловно существуют, только вы почему-то считаете, что при этом никто не додумался сделать "хитрости" и для стека тоже. > Дело привычки, не более. А код, генерируемый современными компиляторами, отлаживать трудно хоть так, хоть эдак. Более того (открою страшную тайну) - GCC в ряде случаев может использовать регистровые вызовы для оптимизации. Я уже понял, что для вас чем сложнее код, тем круче. Только оптимизаторы тоже разные бывают. Есть такие что при оптимизациях не ломают читаемость кода. И насколько нужно оптимизировать по скорости прикладной код - это тоже еще вопрос. Ну, допустим, читаемость ассемблерного кода - это всего лишь факультативная фича. Хотя кому как. И наконец, вы так и не удосужились прикинуть, какую долю занимают разные вызовы и передача параметров от прочих вычислений. У вас получается, что вызовы существуют только ради вызовов. Если конечно у вас не "шитый код". Стековая передача параметров дает простор для большого количества других оптимизаций (и не только по скорости, см. начало).
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	55. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от AlexAT (ok) on 24-Окт-11, 23:11
	> Так вот, оптимизация бывает разной. По скорости, по надежности, по простоте Спасибо, кэп. > А также в оптимизации значение имеет суммарный конечный результат, > а если одни параметры оптимизируются в ущерб других - зачем такая > оптимизация нужна. Открыть секрет? Оптимизация по размеру делается в ущерб производительности почти всегда. И наоборот. Причем именно эти крайности имеют место быть в основном. > Видите ли, в нормальных ОСях (и даже не только в Юниксах) принято > доверять ядру, и не доверять прикладному коду. Видите ли, к точке сохранения и использования регистров это имеет отношения ровно 0.00. > Поэтому стековая передача параметров здесь явно выигрывает. В чём? Примеры в студию. > Само собой речь шла об указателях на структуры. Вот и считайте, сколько > раз вы будете переписывать эти указатели, значения которых не меняются Нисколько. Перезагрузка указателя на фиксированную структуру обычно вообще делается с помощью MOV r,imm, на динамически распределенную - MOV r,mem, если же структура вся помещается на стеке - никакой перезагрузки не нужно. > когда не известно, сколько регистров будет использовано в каждом вызове в ядро Такое и может быть только в ваших системах. У нормальных систем есть ABI, и оптимизаторы о нем знают. > Учтите также в современных программах количество глобальных структур (которые используются для всякого там менеджмента памяти и сборщиков мусора Опа, iZEN, залогиньтесь. > "Хитрости" с регистрами в современных процах безусловно существуют, только вы почему-то > считаете, что при этом никто не додумался сделать "хитрости" и для > стека тоже. Дык пруф где? > Стековая передача параметров дает простор для большого количества других оптимизаций (и > не только по скорости, см. начало). Конечно дает. Особенно при инклюзивных кешах, когда любая запись в стек пролетает несколько уровней кеша, и очередь встает колом из-за ожидания доступа в память.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	56. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от AlexAT (ok) on 24-Окт-11, 23:13
	ЗЫ. Последний тезис - про абстрактные сферические в пределах одной программы. При вызовах в ядро переключение контекста все равно сбрасывает очередь.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	58. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 25-Окт-11, 14:29
	>> А также в оптимизации значение имеет суммарный конечный результат, а если одни параметры оптимизируются в ущерб других - зачем такая оптимизация нужна. > > Открыть секрет? Оптимизация по размеру делается в ущерб производительности почти всегда. И наоборот. Причем именно эти крайности имеют место быть в основном. Ну допустим, здесь я позволил себе допустить небрежность. Следовало сказать не об "одном в ущерб другого". Следовало сказать о балансе в целях оптимизации. Однако высказывание о "суммарном конечном результате" остается в силе. Про размеры вы совершенно правы. Сейчас Винды в лидерах по быстродействию за счет больших объемов и сложности кода. И Linux идет по пятам за ними в этом деле. Об остальных целях оптимизации вы вообще предпочли умолчать. >> Видите ли, в нормальных ОСях (и даже не только в Юниксах) принято доверять ядру, и не доверять прикладному коду. > > Видите ли, к точке сохранения и использования регистров это имеет отношения ровно 0.00. Значит для вас не имеет. Я уже понял, что вы предпочитаете сохранять регистры, не доверяя это ядру, хотя оно это и так делает. А потом рассуждать об оптимизации. > Нисколько. Перезагрузка указателя на фиксированную структуру обычно вообще делается с помощью MOV r,imm, Ну допустим, в этом случае так. Значит видимо в вашем коде преобладают именно статические структуры, когда вам еще на этапе компиляции известно их количество и размеры. Ну да, любители шаблонов С++ любят так развлекаться. А иначе - смотрим далее. > на динамически распределенную - MOV r,mem, если же структура вся помещается на стеке - никакой перезагрузки не нужно. Ну а здесь какой выигрыш? В итоге та же память, тот же стек. Я ведь уже сказал, при оптимизациях надо смотреть на суммарный конечный результат. Убирая из стека в регистры одно, вы будете вынуждены класть туда другое. Если еще учесть, что вы предпочитаете сохранять и восстанавливать одни и те же регистры дважды (см. выше и ранее). > Такое и может быть только в ваших системах. У нормальных систем есть ABI, и оптимизаторы о нем знают. В "наших" системах это называется "Keep it simple, stupid!". Т.е. вы искренне верите, что ABI сообщит вам все варианты ветвления кода в ядре в зависимости от текущего состояния процессора и памяти на момент системного вызова, и все это на этапе компиляции. Оно вам просто сообщит максимальное объединенное множество регистров. Дополнительный источник потенциальных багов. И зачем? Когда ядро все равно в рантайме сохраняет нужные регистры по мере необходимости. Все просто. > ЗЫ. Последний тезис - про абстрактные сферические в пределах одной программы. При вызовах в ядро переключение контекста все равно сбрасывает очередь. Я к непорочной целостности очереди вообще никак не апеллировал. Это вы берете на себя ответственность утверждать, что можете лихо контролировать очередь на этапе компиляции. Ну да. Для колдовства с очередями сейчас много всяких средств придумано. Только "серебряной пулей" они не являются. Ими еще надо знать когда пользоваться. И результат должен окупать затраты, а не наоборот. > Опа, iZEN, залогиньтесь. И это сюда же. Я уже понял, что вы сторонник гадания на кофейной гуще. Так же как с очередью и регистрами. > Конечно дает. Особенно при инклюзивных кешах, когда любая запись в стек пролетает несколько уровней кеша, и очередь встает колом из-за ожидания доступа в память. Т.е. вас как-то от этого спасает сохранение регистров в тот же самый стек, да еще и дважды (когда это и так делает ядро). > В чём? Примеры в студию. > Дык пруф где? Это вы так и не привели в студию примеры ваших "хитростей". Или тотальное использование статических структур - это и есть вся ваша хитрость? Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах, вы по прежнему убеждены, все эти технологии обошли стек стороной. Резюме. В традициях DOSовского наследия выжимать скорость любой ценой, используя любые сомнительные методы оптимизации. Когда скорость растет незначительно, зато комбинаторно пухнет сложность как самого кода, так и инструментов, с помощью которых этот код создается. В традициях же Юниксов - осторожное отношение к оптимизациям. Когда сначала создется правильный код, а уже потом его профилировкой решается, нужно его оптимизировать или нет, и в каких конкретно местах. И не полагаться на интрументы, котрые якобы заранее "все знают", особенно поведение всяких там очередей.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	59. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 25-Окт-11, 15:00
	>> Поэтому стековая передача параметров здесь явно выигрывает. > В чём? Примеры в студию. В простоте, кода и инструментов. Вам нужны примеры простоты? Сложность может выиграть тактику. Простота выигрывает стратегию. Для оптимизаций и выяснения, где именно чаще ломается очередь - есть старая добрая профилировка. Сначала нужно делать простой и правильный код, а потом уже смотреть, где именно возникают узкие мета производительности. А не надеяться на "серебряные пули" на этапе компиляции.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	60. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от AlexAT (ok) on 26-Окт-11, 08:06
	> Значит для вас не имеет. Я уже понял, что вы предпочитаете сохранять > регистры, не доверяя это ядру, хотя оно это и так делает. > А потом рассуждать об оптимизации. Я доверяю ABI, которое однозначно говорит, что надо сохранять. Нормальный оптимизатор переименует регистры перед вызовом. Хотя в случае вызова ядра любая оптимизация смысла не имеет. >> на динамически распределенную - MOV r,mem, если же структура вся помещается на стеке - никакой перезагрузки не нужно. > Ну а здесь какой выигрыш? В итоге та же память, тот же стек. MOV [base+offset],imm - очень неприятная с точки зрения исполнения операция - мало того, что задействуется расчет смещения совместно с доступом в память по расчитанному оффсету (что само по себе уже задница при конвееризации) - так еще и очень длинная команда, декодеру тоже придется несладко. MOV r,imm / MOV r,mem - гораздо выгоднее. Или предлагаете последовательные PUSH imm / PUSH mem для вставки операндов использовать? В x86-архитектуре оные являются блокирующими. Опять же - в случае вызова ядра это бессмысленно. Но мы уже перешли к обсуждению плюсов и минусов конкретной calling convention. > Убирая из стека в регистры одно, вы будете вынуждены класть туда другое. В том и фокус - что в стек ничего не кладется, и из стека ничего не убирается. А регистры придется сохранять даже при передаче параметров через стек. Либо ядру, либо прикладному ПО. Секрет: при передаче параметров через регистры в стек нужно сохранять меньше данных, и перезагрузка выполняется не со стека, а через imm/mem - как уже говорил - эти операции как минимум на x86 оптимальнее. > В "наших" системах это называется "Keep it simple, stupid!". Прикладной уровень амёбы (simple, stupid) - похоже Ваше всё :) Слишком любите эту фразу. > Т.е. вы искренне верите, что ABI сообщит вам все варианты ветвления кода Я верю, что ABI сообщит генератору кода, что надо сохранять, а что нет - и ядро будет следовать ABI. Как уже вами говорилось - ядру надо верить. > И зачем? Когда ядро все равно в рантайме сохраняет нужные регистры по мере необходимости. Все просто. Передача параметров на регистрах позволяет не сохранять их дополнительно во время работы процедуры, если это не заявлено ABI специфично. Меньше мертвого груза - меньше обращений в память. > Это вы берете на себя ответственность утверждать, что можете лихо контролировать очередь на этапе компиляции. На этапе компиляции как раз таки делаются оптимизации выполнения. При вызовах в ядро это не критично, но вот при вызовах в пределах одной программы... >> Конечно дает. Особенно при инклюзивных кешах, когда любая запись в стек пролетает несколько уровней кеша, и очередь встает колом из-за ожидания доступа в память. > Т.е. вас как-то от этого спасает сохранение регистров в тот же самый > стек, да еще и дважды (когда это и так делает ядро). Взгляните вот сюда - поймете. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6... > Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах, > вы по прежнему убеждены, все эти технологии обошли стек стороной. Ну так пруф где? Резюме: привести пруф за 3 сообщения не удосужился, слив защитан.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	61. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 26-Окт-11, 17:49
	>> В "наших" системах это называется "Keep it simple, stupid!". > > Прикладной уровень амёбы (simple, stupid) - похоже Ваше всё :) Слишком любите эту фразу. О, да! Это одна из моих любимых фраз. "(simple, stupid) - похоже Ваше всё" - то есть вы понимаете эту фразу именно так. То есть вы сопоставляете простоту и глупость. Хотя смысл фразы с точность до наоборот. В ней глупость противопоставляется простоте. А для вас, значит, чем проще, тем глупее. И чем сложнее, тем для вас умнее, значит. С вами все ясно. > Опять же - в случае вызова ядра это бессмысленно. Но мы уже перешли к обсуждению плюсов и минусов конкретной calling convention. > > На этапе компиляции как раз таки делаются оптимизации выполнения. При вызовах в ядро это не критично, но вот при вызовах в пределах одной программы... Нет, я не переходил к обсуждению соглашений о вызовах "вообще", я говорил именно о соглашениях при вызовах в ядро. Это вы с вашими рассуждениями о сравнении эффективности "MOV r,mem" и "PUSH/POP", и о  поломках конвейера, ушли в детали оптимизации "вообще", да еще и в привязке к архитектуре x86. > MOV [base+offset],imm - очень неприятная с точки зрения исполнения операция ................ MOV r,imm / MOV r,mem - гораздо выгоднее..............PUSH imm / PUSH mem ... В x86-архитектуре оные являются блокирующими. Если мне профилировка покажет, что именно здесь узкое место, ничто не мешает мне подобные фишки в свой код включить. Только системные вызовы-то тут при чем? А сам по себе системный вызов "блокирующим" по-вашему не является? Вы ранее сами говорили про переключение контекста. У вас что, код состоит из одних системных вызовов, что для вас это так критично? Если у вас слишком много системных вызовов, значит это уже не прикладной код, и проще уже его вставить в ядро в виде модуля и не париться. Обычно, наоборот, оптимизация как раз и заключается в организации обработки данных таким образом, чтобы количество системных вызовов как можно более сократить. > Я верю, что ABI сообщит генератору кода, что надо сохранять, а что нет - и ядро будет следовать ABI. Ну, сообщит, значит еще лучше. И что? Вот именно, что вы слишком верите оптимизаторам, что они вам заранее все предскажут, и как видно не любите пользоваться профилировщиками. Потому что профилировка требует аналитических способностей, а не просто зазубривание рецептов и пихание их везде, где надо и не надо, ценой усложненния кода. Если рецепт в одном случае хорошо себя проявил, это не значит, что он даст такие же показатели во всех случаях. А если вы сами ассемблерный код не пишите, а пользуетесь исключительно оптимизаторами, то вы вообще эту разницу не почувствуете, как именно производятся системные вызовы. Вы конечно опять назовете меня К.О., и задним числом заявите, что вы это все и раньше якобы знаете. Однако все же замечу, что профессиональная (нерецептурная) оптимизация делается по-другому. Сначала создается простой и правильный код без оптимизаций. Потом профилировкой выясняются узкие места. Сокращаются временные характеристики алгоритмов O[f(n)]. А описанные вами проблемы, связанные с задержками памяти по отношению к регистрам - это всего лишь линейный множитель к общему времени работы алгоритма. А это все оптимизируется в последнюю очередь. Бездумно вставляя рецепты по оптимизации ценой усложнения кода, вы лишь отрубаете себе возможность оптимизировать код в дальнейшем, когда это будет действительно нужно. Вы просто не знаете, что такое UNIX, зачем это создавалось и в каких средах работает. И узким местом являются там каналы передачи данных и межпроцессное взаимодействие, и уж точно не быстродействие памяти. И приоритетом в Юниксах являются надежность, правильность и безопасность, а уж потом только скорость. А вы своими рассуждениями, лишь уточнили ту целевую аудиторию, для которой DOS/Linux предназначен. >> Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах, >> вы по прежнему убеждены, все эти технологии обошли стек стороной. > > Ну так пруф где? > Резюме: привести пруф за 3 сообщения не удосужился, слив защитан. Если ничего этого нет, то это мой слив. А если это есть, значит вы просто находитесь во власти стереотипов. Еще одна подсказка вам: попробуйте посмотреть на процессор и стек не с точки зрения стереотипов того ассемблера, к которому вы привыкли, а еще и с точки зрения самой схемотехничекой и математической сути этих артефактов (т.е. созданных людьми технологий и предметов).
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	49. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Ytch on 23-Окт-11, 23:58
	>>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то >> >> Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти. >Вы видимо не знаете более достойного использования регистров, пусть даже если регистров большое количество, пусть даже целые регистровые файлы, - кроме как забивание их параметрами процедур. >Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других структур данных в современных программах. >Вторая подсказка - учитывая вами же высказанное соотношение скорости доступа к регистрам и к памяти - если вас волнует быстродействие, следует посчитывать все вычисления в программе, а не только вызовы процедур. Если регистры используются для передачи/возврата значений функций, это вовсе не значит, что они больше не могут быть использованы ни для чего. Оптимизатор не "держит" их специально в резерве на случай вызова функции, они используются полноценно - никакой потери эффективности здесь нет. Насчет "нормальных юниксов" стоит вспомнить историю и различные архитектуры процессоров: 1. в большинстве старых архитектур (да и в некоторых относительно новых) регистры были, мягко выражаясь, неравнозначны и количество их было минимально (каждый служил для определенной цели и не мог быть заменен любым другим). 2. частоты ядра и шин отличались друг от друга не на порядки (как сейчас) и были существенно скромнее нынешних, то есть работа с памятью не была такой накладной по отношению к общей производительности (сейчас многоуровневые кеширования, конечно, отчасти помогают приблизиться к тому же самому, но кеш есть кеш). 3. реализовывать проще что-то одно: либо только стек, либо только регистры, но случай "только регистры" в реальной жизни не вариант, поэтому он становится как бы гибридной схемой, то есть сложнее для реализации. Учитывая все это, единственным нормальным вариантом в то время была передача строго через стек. Вот оттуда и тянутся корни. DOS (а впоследствии и Linux) не были "отягощены" этим историческим наследием (ни в программном, ни в аппаратном смысле), поэтому и сделали вариант посложней, но и поэффективней. Можно еще вспомнить про виртуальную память, но уже и так достаточно... P.S. Cправедливости ради, стоит отметить, что на современной аппаратуре схема "только стек" не настолько уж хуже - иначе от нее давно бы избавились несмотря на "наследие прошлого".
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 24-Окт-11, 08:56
	> Учитывая все это, единственным нормальным вариантом в то время была передача строго через стек. Вот оттуда и тянутся корни. DOS (а впоследствии и Linux) не были "отягощены" этим историческим наследием (ни в программном, ни в аппаратном смысле), поэтому и сделали вариант посложней, но и поэффективней. Вы неправильно все интерпретируете. Как раз таки наследие DOS и "отягощено" привязкой к конкретному процессору - 8086 (плюс небольшие его расширения типа 80286). И опять-таки, начиная с i386 ДОСовский, "вариант" действительно сложнее, но вовсе не эффективней. (Ну может в некоторых частных случаях и эффективней, но речь шла о вызовах в ядро. А иначе, и в Юниксах внутри одного модуля никто не запрещает передавать параметры в регистрах, если действительно нужно.) Что же касается Юниксов, то тут надо говорить не о "старых" и "новых" процах (часто новое - это хорошо забытое старое), а о том, что разных процессоров было и есть великое множество, чего "наследие DOS" совершенно не учитывает. > P.S. Cправедливости ради, стоит отметить, что на современной аппаратуре схема "только стек" не настолько уж хуже - иначе от нее давно бы избавились несмотря на "наследие прошлого". Вот именно. См. в постах выше. И не забывайте, что речь шла прежде всего о вызовах в ядро. А не просто о сферическо-вакуумных вызовах процердур в нутри одного кода.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

20. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от Аноним (??) on 21-Окт-11, 22:55
aufs разьве не заменяет unionfs ? Или я туплю и его нету в ванильном ядре?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 24-Окт-11, 13:53
	aufs как раз является "вариантом файловой системы в стиле unionfs". Но в ваниле таких ФС нет и не будет, Торвальдс в свое время высказался достаточно жестко.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

21. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от Андрей (??) on 21-Окт-11, 23:31
"В механизм нотификации fanotify..." Да, и монтирование - это изменение! Плиз, добавьте! Каких только "выстрелить себе в ноге" не наёдёшь, чтобы мониторить такую вещь как монтирование!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
Сообщение от pavlinux (ok) on 22-Окт-11, 02:32
Мечты. 0. Верните /dev/XOR 1. Нужны /dev/aes, /dev/blowfish, /dev/gost, ...   $echo "$HOME/secret.key"  > /proc/crypto/aes_key $cat $HOME/Gogovoy_otchet.odt > /dev/aes > $HOME/Мы\ На\ Море.JPG 2. Собранный воедино, в человеческом, читаемом виде лог ошибок железа,    отсутствующих и лишних компонент ядра. А не зоопарк раскиданный по    всему /var/log, /sys и /proc 3. Возможность сбора статистики используемых компонент, тех, которые    возможно включать/выключать через конфигуратор.    Вот к примеру только на днях обнаружил, что в ядре висит параметр    CONFIG_LLC2. А протоколы LLC я уж точно года 2-3 не юзаю, и конфиг    тянется от туда.    Хорошо когда домашний комп, его можно трахать ночами на пролёт, изучая    порегистрово каждую компоненту. А вот пересобрать ядро для свежеприбывшего    сервака, дай Бог со второй-третьей компиляции удастся. 4. Системные вызовы setpid()/setppid(), reserve_pid_space()      Ну вот хочу я чтоб у моего сервака были красивые номера :)    типа 1111, 2222, 3333,      reserve_pid_space() - для гарантии что все процессы от 22222 до 22999    будут принадлежать мне.      Для антифлуда сделать sysctl -w kernel.max.pids_space=100   5. Вызовы attachpid(pid_t)/deattachpid(pid_t)/canbeattached(struct *attr)    для присоединения процессов.    API для присоединения любого процесса, обладающего соответствующими    разрешением и возможностью, для исключения прослойки IPC.    Иными словами, возможность объединения всех, выбранных или разрешённых атрибутов    двух процессов, таких как адресное пространство, переменные, открытые файлы, и т.д.   Шоб нах...й выкинуть эти сокеты/пайпы/шмем/семафоры/сигналы, и пр. ацтой XX века. 6. nice, renice и chrt должны действовать не только на планировщик задач и    очередь к процессору, но и на ввод/вывод, сетевую подсистему, память, и т.д. 7. Хотя бы примитивный искусственные интеллект с предсказаниями для SMP-балансировщика,    чтоб после 500 раз форков апача он уже понимал, что каждый 50-й надо сразу форкать    на новый процессор/ядро, а не ждать пока ядро загрузиться до 101%    8. Организации в планировщике внутренней таблицы приоритетов, помимо PRI и NICE,    для распределения очереди с учётом простаивающих и редко используемых процессов.        Некое подобие RoundRobin c отстойником.    К примеру, на Debian 6 как некрути, да же если не LPT порта, модуль parport_pc,    всё равно загружается. Так вот, надо чтоб планировщик загнал его в такую жопу,    что только первое обращение к его функциям и сам процесс вынимания из этого    отстойника занимал бы секунд 10. :) 9999999. Вы меня эта, остановите, а то я неделю могу генерить недостатки и пожелания ядра. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 22-Окт-11, 15:02
	> 7. Хотя бы примитивный искусственные интеллект с предсказаниями для SMP-балансировщика, >    чтоб после 500 раз форков апача он уже понимал, > что каждый 50-й надо сразу форкать >    на новый процессор/ядро, а не ждать пока ядро загрузиться > до 101% И тут внезапно шиндошс, глюки, маты админов, что что-то работает не так, как ожидалось и тп.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	36. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 03:34
	>Мечты. >0. Верните /dev/XOR > ... Pavlinux, ты реально крут. Очень надеюсь что пожелания уже успел отправить девелоперам. Я уверен, что если и kernel-хакеры не реализуют все или какую-то часть, то ваши пожелания, как минимум, получать широкую огласку, что увиличивает (потенциально) щансы на улучшения. Ну а если у вас есть напористость - то вполне можете завести дискуссию и остаивать необходимые пунткы. То что вы понаписали сильно может улучшить ядро. Это очень хорошо.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от Какаянахренразница on 22-Окт-11, 10:38
А где список пожеланий, которые были в предыдущей редакции, но не вошли в нынешнюю, ибо УЖЕ ВЫПОЛНЕНЫ? Или несть таких?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Aquarius (ok) on 22-Окт-11, 11:33
	так быстро? однако, вы фантазер, батенька
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	39. "Новая редакция списка возможностей, которых не хватает в ядр..."	+1 +/–
	Сообщение от fyjybvec on 23-Окт-11, 04:27
	По первому списку я видел несколько патчей в течение дня-двух, дальше не отслеживал.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

37. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
Сообщение от Аноним (??) on 23-Окт-11, 03:57
не отказался бы от сжатия tmpfs с, скажем, LZO. а то 4х гектаров мозгов уже еле хватает, чтобы фуррифокс 8-ой собрать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 04:09
	ZRAM?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	40. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 05:05
	опа-це! спасибо за наводку!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	43. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 14:32
	Как просто открывался ларчик. Кстати, если 4 гектар мозгов не хватает на какую-то сборку, я бы всерьез подумал о качестве всего мемори менеджмента в ядре. Как-то фиговато-вато-этово это выглядит. Чай, не Оракл собирать.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	57. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Aquarius (ok) on 25-Окт-11, 06:05
	> Как просто открывался ларчик. Кстати, если 4 гектар мозгов не хватает на > какую-то сборку, я бы всерьез подумал о качестве всего мемори менеджмента > в ядре. Как-то фиговато-вато-этово это выглядит. Чай, не Оракл собирать. а почитать внимательнее если? речь идет о tmpfs, то есть об использовании памяти в качестве контейнера для того, что принято называть виртуальным диском
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	47. "Новая редакция списка возможностей, которых не хватает в ядр..."	+/–
	Сообщение от Аноним (??) on 23-Окт-11, 23:55
	> ZRAM? Это пожатый рамдиск, а не тмпфс. Хотя при использовании зрам в случае, если не будет хватать памяти, то данные tmpfs будут улетать на него и, соответственно, сжиматься.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема