Тут нада чота умное напейсать! Шоб сказал, как отрезал! Но чота ничо не приходит вголову, сцуко (( :D
Надо тут записать, чо я узнал про Линукс, а то ж забуду на хер.
читать дальшеВ общем, читаю я энту книжку "Современные Операционные Системы". Осилил 4 главы, заебался и перескочил сразу на 10ю, где про Линукс и Ондроед. Не, она легко читается, просто мне невтерпёж было узнать конкретные решения, а не то, как вообще можно.
В общем, идро это в первую очередь структуры данных. Их там до жопы.
1) нужно управлять процессами, коих там в обычном режиме нескоко сотен - у меня вот 245. На серверах, понятно, ещё больше
2) нужно управлять памятью
3) нужно управлять вводом-выводом, а это у нас сеть, диски, NFS и терминалы и ваще нужно управлять периферийными устройствами, хотя это в общем-то и есть ввод-вывод
4) модули ядра нужно подгружать и удалять, а это тоже данные
Всё это хозяйство обладает неебическим количеством параметров, которые между собой связаны и все их надо отслеживать. Например - взаимодействие между процессами - семафоры, мьютексы, фьютексы и хз чо ещё.
Ядро постоянно находится в памяти (за исключением подгружаемых модулей)
Также постоянно находится в ОЗУ карта памяти - для управления собственно памятью. Чего кому выделено, скоко свободно, что сейчас в ОЗУ, а что в свопе и т.д.
Ещё в памяти содержацца собсно процессы, а ещё страничный/дисковый кэш. Раньше (до 2.6 или 2.2) эти кэши были раздельно, но потом пришли к выводу, что это неэффективно и соединили. Если вы набираете free -h... кстати, в некоторых дистрах есть free -h и free -g, а в некоторых нет - есть токо free -m. Ёбаные красноглазики! Трудно им штоле блядь договорицца и заюзать единое free хотя бы? Ну про swapon / swapon -s йа уже тут пейсал. Но мы отвлеклись.
Короче, если вы набираете free -m и видите, что у вас осталось совсем мало памяти, а buffers / cache отожрал до хера - это всё фигня. В любой момент этот кэш может быть сброшен почти до нуля и память таким образом освобождена. Там и цифра даже отдельная печатается - свободная память вместе с буферами. Дело в том, что, например, данные пишутся не сразу на диск, а сначала собираются в определённом месте в памяти, специальный планировщик ввода-вывода группирует их так, чтобы близкие блоки располагались близко и за один заход записало как можно больше. Именно поэтому комп сразу нельзя выключать, а надо хотя бы сделать sync - тогда содержимое сбросицца на диск. Процесс pdflush как раз занимается сбросом страниц на диск. В некоторых случаях система делает упреждающее чтение с диска, если считает, что эти данные скоро понадобятся - это тоже хранится в кэше. Каталоги ФС тоже кэшируются в памяти, чтобы каждый раз их не считывать в поисках номеров i-узлов. Когда процесс освобождает память, освобождённые страницы какое-то время ещё висят в кэше на случай, если понадобятся снова. В общем, так бы оперативка просто простаивала без дела, а с помощью кэша выполняет полезную функцию - повышает производительность.
Файловая система ext4 это ext2 + журналирование. Можно было бы писать в журнал не только изменения в i-узлах, но и изменения данных в файлах. В этом случае при выключении компа не потерялось бы ничего. Но, в целях совместимости, экономии и хз чего ещё этого сделано не было. В журнал пишутся только метаданные файловой системы - т.е. данные об i-узлах, изменения в списке свободных и занятых блоков. Короче, при внезапном выключении структура ФС должна выжить, а данные в файлах могут быть повреждены. Не во всех файлах, а токо в тех, которые были изменены и не были сброшены на диск на момент выключения. ext4 выделяет дисковое пространство не блоками, а экстентами по 128 Мбайт штоле. Как-то там благодаря этому получается создавать файлы бОльшего размера, чем если бы блоками (до 16 Тбайт вроде). А в ext3 всё скромнее - до 2Гбайт и макс размер ФС 16Тбайт. Значит, ext3 не экстентами выделяет.
В i-узле ext4 имеется 10 дыр для блоков, из которых будет состоять файл. А также по одной дыре для одинарного, двойного и тройного косвенного блока - т.е. таких блоков, которые указывают на блоки с блоками. А я вот думал, шо если уж используются косвенные блоки, то весь i-узел будет состоять токо из них: если двойные, то 10 двойных, тройные - 10 тройных. Нее, хер там.
В ядре имелся старый планировщик задач О1. Как он был устроен - там есть 100 системных приоритетов и 40 пользовательских, всего 140 приоритетов. Было два массива - истёкших задач и выполняющихся. Каждый массив состоял из 140 двунаправленных списков - по числу приоритетов. Сначала расходовали выделенное им время задачи с высоким приоритетом, потом всё ниже и ниже. Как только квант времени задачи заканчивался, она переносилась в массив истёкших задач. Как только массив выполняющихся задач становился пустым, массивы менялись местами. У планировщика имелись недостатки чо-то там с интерактивными задачами он косячил.
Далее и видимо сейчас его заменил планировщик FCS - чо-то там "абсолютно честный". Сделан на основе красно-чёрного дерева. Хз, что это значит, ну видимо, эти самые два массива объединили в дерево, истёкшие задачи становятся красными или там чёрными, потом всё в другую сторону. Задачи рассортированы по времени выполнения, планировщик как-то там обходит узлы и меняет местами задачи. Вот, объяснил. Ну можете поискать, название планировщика у вас есть.
читать дальшеВ общем, читаю я энту книжку "Современные Операционные Системы". Осилил 4 главы, заебался и перескочил сразу на 10ю, где про Линукс и Ондроед. Не, она легко читается, просто мне невтерпёж было узнать конкретные решения, а не то, как вообще можно.
В общем, идро это в первую очередь структуры данных. Их там до жопы.
1) нужно управлять процессами, коих там в обычном режиме нескоко сотен - у меня вот 245. На серверах, понятно, ещё больше
2) нужно управлять памятью
3) нужно управлять вводом-выводом, а это у нас сеть, диски, NFS и терминалы и ваще нужно управлять периферийными устройствами, хотя это в общем-то и есть ввод-вывод
4) модули ядра нужно подгружать и удалять, а это тоже данные
Всё это хозяйство обладает неебическим количеством параметров, которые между собой связаны и все их надо отслеживать. Например - взаимодействие между процессами - семафоры, мьютексы, фьютексы и хз чо ещё.
Ядро постоянно находится в памяти (за исключением подгружаемых модулей)
Также постоянно находится в ОЗУ карта памяти - для управления собственно памятью. Чего кому выделено, скоко свободно, что сейчас в ОЗУ, а что в свопе и т.д.
Ещё в памяти содержацца собсно процессы, а ещё страничный/дисковый кэш. Раньше (до 2.6 или 2.2) эти кэши были раздельно, но потом пришли к выводу, что это неэффективно и соединили. Если вы набираете free -h... кстати, в некоторых дистрах есть free -h и free -g, а в некоторых нет - есть токо free -m. Ёбаные красноглазики! Трудно им штоле блядь договорицца и заюзать единое free хотя бы? Ну про swapon / swapon -s йа уже тут пейсал. Но мы отвлеклись.
Короче, если вы набираете free -m и видите, что у вас осталось совсем мало памяти, а buffers / cache отожрал до хера - это всё фигня. В любой момент этот кэш может быть сброшен почти до нуля и память таким образом освобождена. Там и цифра даже отдельная печатается - свободная память вместе с буферами. Дело в том, что, например, данные пишутся не сразу на диск, а сначала собираются в определённом месте в памяти, специальный планировщик ввода-вывода группирует их так, чтобы близкие блоки располагались близко и за один заход записало как можно больше. Именно поэтому комп сразу нельзя выключать, а надо хотя бы сделать sync - тогда содержимое сбросицца на диск. Процесс pdflush как раз занимается сбросом страниц на диск. В некоторых случаях система делает упреждающее чтение с диска, если считает, что эти данные скоро понадобятся - это тоже хранится в кэше. Каталоги ФС тоже кэшируются в памяти, чтобы каждый раз их не считывать в поисках номеров i-узлов. Когда процесс освобождает память, освобождённые страницы какое-то время ещё висят в кэше на случай, если понадобятся снова. В общем, так бы оперативка просто простаивала без дела, а с помощью кэша выполняет полезную функцию - повышает производительность.
Файловая система ext4 это ext2 + журналирование. Можно было бы писать в журнал не только изменения в i-узлах, но и изменения данных в файлах. В этом случае при выключении компа не потерялось бы ничего. Но, в целях совместимости, экономии и хз чего ещё этого сделано не было. В журнал пишутся только метаданные файловой системы - т.е. данные об i-узлах, изменения в списке свободных и занятых блоков. Короче, при внезапном выключении структура ФС должна выжить, а данные в файлах могут быть повреждены. Не во всех файлах, а токо в тех, которые были изменены и не были сброшены на диск на момент выключения. ext4 выделяет дисковое пространство не блоками, а экстентами по 128 Мбайт штоле. Как-то там благодаря этому получается создавать файлы бОльшего размера, чем если бы блоками (до 16 Тбайт вроде). А в ext3 всё скромнее - до 2Гбайт и макс размер ФС 16Тбайт. Значит, ext3 не экстентами выделяет.
В i-узле ext4 имеется 10 дыр для блоков, из которых будет состоять файл. А также по одной дыре для одинарного, двойного и тройного косвенного блока - т.е. таких блоков, которые указывают на блоки с блоками. А я вот думал, шо если уж используются косвенные блоки, то весь i-узел будет состоять токо из них: если двойные, то 10 двойных, тройные - 10 тройных. Нее, хер там.
В ядре имелся старый планировщик задач О1. Как он был устроен - там есть 100 системных приоритетов и 40 пользовательских, всего 140 приоритетов. Было два массива - истёкших задач и выполняющихся. Каждый массив состоял из 140 двунаправленных списков - по числу приоритетов. Сначала расходовали выделенное им время задачи с высоким приоритетом, потом всё ниже и ниже. Как только квант времени задачи заканчивался, она переносилась в массив истёкших задач. Как только массив выполняющихся задач становился пустым, массивы менялись местами. У планировщика имелись недостатки чо-то там с интерактивными задачами он косячил.
Далее и видимо сейчас его заменил планировщик FCS - чо-то там "абсолютно честный". Сделан на основе красно-чёрного дерева. Хз, что это значит, ну видимо, эти самые два массива объединили в дерево, истёкшие задачи становятся красными или там чёрными, потом всё в другую сторону. Задачи рассортированы по времени выполнения, планировщик как-то там обходит узлы и меняет местами задачи. Вот, объяснил. Ну можете поискать, название планировщика у вас есть.
-
-
30.06.2018 в 18:36это просто сбалансированное бинарное дерево такое
сбалансированное = высота всех листьев примерно одинакова
бинарное = на каждом уровне от 1 предка ветвятся 2 потомка
-
-
01.07.2018 в 10:34Хотя... ну и почитаю я про них, и что? Чо поменяется-то. Будут пылицца ценные знания на чердаке, вот, если бы это можно было как-то применить... Хотя всё равно почитаю. Ну или в какой-нить ближайшей книжке про Линукс более подробно всё объяснят.
Я вот тут про книги пейсал, мож те тоже интересно будет gina2010.diary.ru/p215681606.htm и в комментах там ещё есть. А мож ты уже читал что-нить из этого?