Комментарии 14
Пролистал до конца "статьи" и не прогадал, что в конце будет ссылка не телегу. Маркер, что с большой вероятностью это будет просто оберткой над ссылкой.
Я просто оставлю это здесь
Каждый сегмент имеет свой собственный размер и базовый адрес в физической памяти.
Нет, базовый адрес сегмента — это линейный адрес, а не физический. Они не тождественны в общем случае, и только если бит PG в CR0 выключен, линейный адрес будет численно равен физическому.
Но главное, что поскольку это именно линейный адрес, сегмент может быть и как угодно фрагментирован в физпамяти, а сточки зрения кода это будет непрерывный блок.
Каждый из этих регистров хранит базовый адрес соответствующего сегмента.
Нет, не хранит. В реальном режиме он хранит индекс параграфа физпамяти, к которому будет приплюсовано смещение.
В защищенном режиме он хранит селектор, который состоит из битовых полей, отдельные биты которого задают индекс дескриптора сегмента в глобальной/локальной таблице дескрипторов.
Но, что это интересно, в исходном ошибочном утверждении таки есть доля правды: с введением защищенного режима у сегментных регистров появилась невидимая пользователю теневая часть, в которую процессор заносит базу, лимит, атрибуты доступа соответствующего сегмента, чтобы затем при каждом обращении к сегменту не читать эту информацию из GDT/LDT. То есть это такой кеш для текущего элемента GDT/LDT.
Эта модель была широко использована в ранних компьютерных системах и операционных системах, таких как Intel 8086/8088, и была частично сохранена в более поздних архитектурах x86.
Чего это частично? По мере развития 8086/80186/80286/80386/80486/80586 от сегментов никто не отказывался и их функциональность никак не урезал. Наоборот, появились регистры FS и GS.
Это только в amd64 решили рубить с плеча, потому что парадигма поменялась: раньше инновации в области процессорных архитектур мотивировали системных арограммистов на интересные решения в системном софте, а теперь тупо спрос рождает предложения.
Сегментная модель: может страдать от внешней фрагментации, когда различные сегменты разбросаны по физической памяти, что может затруднить выделение больших блоков для выполнения задач.
Как раз таки не страдает, в отличие от архитектур с flat-моделью памяти. Вот единое адресное пространство процесса очень легко фрагментировать микровыделениями, так, что свободно будет 80%, но нельзя будет выделить непрерывный блок, размером хотя бы 20% от суммарного объема свободной части АП.
А вот с сегментами такой проблемы нет, она есть только на уровне фрагментации линейного адресного пространства. Ах, если бы инженеры Intel сделали PDBR не в составе CR3, а в составе дескриптора сегмента... в этом случае проблема фрагментации была бы решена на корню.
Но и без этого, фрагментацию линейного адресного пространства можно было бы решить дефрагментацией: блоки данных можно было в нужные моменты времени сдвигать/раздвигать в линейном АП, чтобы устранить или расширить гэпы. При этом даже копирование данных не пришлось бы делать: достаточно править PDE/PTE, меняя трансляцию линейных адресов в PFN-ы.
В любом случае, для прикладного кода, который оперирует только селекторами, переезд содержимого сегмента в линейном АП вообще никак не останется замеченным: селектор тот же, смещения те же.
А вот с фрагментацией плоского АП сделать нельзя абсолютно ничего: нельзя разрозненные блоки памяти сдвинуть вместе, потому что программа держит миллион адресов, указывающих внутрь этих блоков, и все они станут недействительными.
Во-первых, если писать обзорную статью и говорить о "сферической ОС в вакууме", то останавливаться на сегментации, применяемой в интеловской архитектуре (IA-32 aka x86), нет никакого смысла: рассказывать надо об общих идеях, а не о специфических реализациях. То же относится к конкретным разновидностям файловых систем и т.д. и т.п.
Во-вторых, останавливаться в обзорной статье на интеловском механизме сегментации смысла нет ещё и потому, что 1) он специфичен для интеловской архитектуры, и в других архитектурах ничего подобного нет; и 2) он оказался крайне неудачным, и им пользовались только потому, что были вынуждены. Когда появился 80386 с его нормальным MMU "как у всех", от сегментации, по сути, отказались и используют плоское адресное пространство. Естественно, технически без сегментации обойтись всё равно невозможно, так как этого требует аппаратура, но сегментные регистры настраиваются ОС так, что используется единое плоское адресное пространство -- т.е. технически сегментация есть, а логически -- нет. Ну а AMD, расширяя архитектуру до 64 битов, в 64-разрядном режиме вообще сегментацию, по большому счёту, выпилила: если память не изменяет, FS и GS можно использовать как дополнительные базовые регистры, но сегментов как таковых, со всеми их атрибутами, уже нет; они сохраняются только в 16/32-разрядных режимах для обеспечения обратной совместимости.
Ну а в-третьих, в "ранних компьютерных системах" сегментной модели как раз не было. Когда появилась поддержка виртуальной памяти, она сразу была организована по страницам, причём у разных архитектур отличия лишь технические, но не концептуальные. Сегментацию, вполне возможно, придумала Интел -- и ничего хорошего из этого не вышло. (Замечу попутно, что под сегментацией и в статье, и мною понимается то, как это определено в интеловской архитектуре; само слово "сегмент" применяется и в других архитектурах, но имеет совершенно иной смысл. Например, в IBM System/370 таблицы переадресации, лежащие в основе работы MMU, имеют два уровня: на нижнем лежат таблицы страниц, а на верхнем -- таблицы сегментов; в современной IBM z/Architecture уровней уже пять: помимо классических таблиц сегментов и страниц, пришедших с некоторыми расширениями из Системы 370, там реализовали три уровня таблиц регионов, чтобы эффективно управлять всем 64-разрядным виртуальным адресным пространством).
На мой взгляд, статья никуда не годится.
Ядро это мозг. Спасибо, объяснили. А что тогда печень и почки? На самом деле, насколько я понимаю, ядро это код, который постоянно загружен в память (в отличие от процессов, которые могут заканчиваться или временно прерываться).
И хотел бы я знать, как новичок поймёт выражение "у каждого процесса собственная оболочка"?
И т.д.
На самом деле, ядро даже не обязано целиком быть в памяти. Скажем, в древней OS/360 (вообще, кажется, первая "большая" и "настоящая" ОС в истории) и во вполне современной Винде часть кода ядра находится в памяти постоянно, а часть -- по нужде (хотя механизмы подгрузки/выгрузки кода пространства ядра в этих двух системах кардинально различаются).
Это вопрос терминологии. Можно при желании обьявить то, что погружается, не-ядром.
Но вообще разные ОС гораздо больше отличаются друг от друга, чем можно понять из этой статьи. Например, в мейнфремах нет понятий директорий и файл. Наиболее близкое к понятию "файл" там называется dataset. A в AS/400 file это директорий, внутри которого лежит member.
Кроме того, есть ещё вопрос, что такое вообще ОС. От этого, например, зависит холиварный вопрос "является ли Android разновидностью Linux". Во времена моего детства во всех учебниках было написано: ОС состоит из того, другого, и компиляторов. Сейчас, как-то, все привыкли к тому, что ни одного компилятора на компьютере может и не быть.
Применительно к ядру насчёт терминологии не соглашусь. Точней, объявить-то можно, но вопрос заключается в режиме работы процессора при исполнении этого кода: именно он определяет, ядро это (работа в привилегированном режиме) или не ядро (работа в непривилегированном режиме). В остальном -- да, согласен.
А разве ядро не может позволить постороннему процессу работать в привилегированном режиме?
В принципе, может. Но обычно такой возможностью не пользуются (и я не знаю, где это возможно, кроме OS/360 с её MODESET). Плюс, ещё в каком адресном пространстве находится исполняемый код (у OS/360 тут тоже неоднозначно: изрядная часть системного по своей сути кода, насколько помню, грузилась в разделы задач пользователей).
Нет сходимости:
Если уменьшить часть виртуального адреса, отвечающая за номер страницы, то количество страниц уменьшится, а размер одной страницы увеличится, и полностью наоборот, если уменьшить размер одной страницы, то количество возможный страниц, уменьшиться, а размер одной страницы увеличится.
NTFS(New Technology File System):
Ограничения по размеру файла и раздела:
Максимальный размер файла: 16 ЭБ (экзабайт).
Максимальный размер раздела: 256 ТБ.
Погодите-ка. Давайте разберём эти странные цифры из википедии.
16 экзабайт - это теоретический максимум размера файла для NTFS. Максимальный имплементированный размер файла - 8 PB. 256 TB минус 64 килобайта - это максимальный размер раздела с размером кластера 64Кб. Максимальный размер кластера, поддерживаемый NTFS - 2MB. Максимальный теоретический размер раздела для 2MB кластера - 32*256 TB?
Судя по всему, имеет смысл все-таки говорить о том, что имплементировано, и это, похоже, 8PB c кластером 2Mb для раздела и столько же для максимального размера файла.
Что такое операционная система и зачем она нужна?