Comments 26
Красиво, блин.
Интересно, а что из себя будет представлять граф загрузки Linux?
Интересно, а что из себя будет представлять граф загрузки Linux?
Не знаю. Попробуйте =)
Держите, отрыл свой старый
Еще было бы неплохо посмотреть на загрузку Windows 8, ведь Microsoft неплохо поработал в этом направлении.
Вы не поверите, но недавно об этом задумывался. Спасибо вам :)
Глядя на картинку я сначала подумал статья будет о сложном реалтайм рендеринге загрузочной анимации.
Microsoft предоставляет профайлер загрузки,
habrahabr.ru/post/106684/
Но сделать свой велосипед всегда увлекательно
habrahabr.ru/post/106684/
Но сделать свой велосипед всегда увлекательно
Это не профайлер загрузки, даже не близко. И профайлер не даст вам информации о зависимости. Пост не читали =)
Вообще-то это в том числе и профайлер (и sampled, и instrumented). В том числе и загрузки.
Если под «информацией о зависимости» Вы имеете в виду информацию о том, какой процесс загрузил образ, то эта информация доступна.
Ну и чтоб два раза не вставать, пара небольших замечаний (сразу скажу, что несмотря ни на что статья мне понравилась — интересный подход к сбору данных и очень красивая визуализация результата — браво).
1. Сама методология несколько… натянута, что ли. То, что ввод/вывод занимает большую часть времени при загрузке современных ОС (включая Windows) — это в целом правда (по крайней мере на обычном десктопном «железе»), но меппинг секций достаточно слабо корреллирует со вводом/выводом во время загрузки по как минимум двум причинам: a) то, что секция отображена в память ничего не говорит о том, сколько всего страниц будет иметь hardfault (Вы и сами упомянули, что меппинг не означает исполнение кода, но он не означает и то, что хоть одна страница будет фактически прочитана с диска); b) при «правильной» работе ReadyBoot, именно на его долю будет приходится основная часть ввода/вывода при загрузке, а страницы в секции будут впечатываться прямиком из стендбай списка.
2. Выводы по сервисам тоже не совсем верны. svchost — это не SuperFetch, а Service Host Process. Практически все inbox сервисы в Windows находятся в dll-ках, а разные svchost-ы объединяют сервисы с одинаковыми привилегиями внутри одного процесса. На картинке ниже SuperFetch (System Maintenance Service или SysMain) — всего лишь один из множества сервисов, хостящихся не только в svchost-ах, но и конкретно в svchost (1052)
Если под «информацией о зависимости» Вы имеете в виду информацию о том, какой процесс загрузил образ, то эта информация доступна.
Ну и чтоб два раза не вставать, пара небольших замечаний (сразу скажу, что несмотря ни на что статья мне понравилась — интересный подход к сбору данных и очень красивая визуализация результата — браво).
1. Сама методология несколько… натянута, что ли. То, что ввод/вывод занимает большую часть времени при загрузке современных ОС (включая Windows) — это в целом правда (по крайней мере на обычном десктопном «железе»), но меппинг секций достаточно слабо корреллирует со вводом/выводом во время загрузки по как минимум двум причинам: a) то, что секция отображена в память ничего не говорит о том, сколько всего страниц будет иметь hardfault (Вы и сами упомянули, что меппинг не означает исполнение кода, но он не означает и то, что хоть одна страница будет фактически прочитана с диска); b) при «правильной» работе ReadyBoot, именно на его долю будет приходится основная часть ввода/вывода при загрузке, а страницы в секции будут впечатываться прямиком из стендбай списка.
2. Выводы по сервисам тоже не совсем верны. svchost — это не SuperFetch, а Service Host Process. Практически все inbox сервисы в Windows находятся в dll-ках, а разные svchost-ы объединяют сервисы с одинаковыми привилегиями внутри одного процесса. На картинке ниже SuperFetch (System Maintenance Service или SysMain) — всего лишь один из множества сервисов, хостящихся не только в svchost-ах, но и конкретно в svchost (1052)
Вообще-то я говорю про свою поделку — это не профайлер, и не предназначен был для каких-то количественных оценок производительности. Мне нужна была последовательность загрузки. Я же ничего нигде не считал. =)
1. Согласен с заметками о том, что файлы не будут полностью прочитаны с диска, только частично. Однако минимум нужно прочитать с диска данные о структуре файла и разобрать PE заголовок.
2. Я и не говорил, что svchost — это SuperFetch, в курсе, что сервисы составные. Но так все эти dllки в графе по радиусу и расставлены.
1. Согласен с заметками о том, что файлы не будут полностью прочитаны с диска, только частично. Однако минимум нужно прочитать с диска данные о структуре файла и разобрать PE заголовок.
2. Я и не говорил, что svchost — это SuperFetch, в курсе, что сервисы составные. Но так все эти dllки в графе по радиусу и расставлены.
> Вообще способов оказаться загруженным в память у модуля много. Например, достаточно запросить информацию из ресурсов исполняемого файла, в том числе его иконку.Хм, значит забитый ярлычками «рабочий стол» и меню «пуск» увеличивает время загрузки системы? Всмысле, я всегда это подозревал, но теперь нашёл этому подтверждение =)
Сложно однозначно ответить. Для отображения иконки, например, нужна только секция ресурсов.
еще во времена не NT-шных версий виндоус, когда все любили играться с PE файлами я заметил тот факт, что даже дефективные исполняемые файлы часто отдавали свои ресурсы без каких либо проблем. Думаю ресурсы загружаются без инициализации модуля.
Ну как сказать, не то чтобы прямо, но и совсем не косвенно.
Когда explorer Загружается, он показывает рабочий стол, чтобы показать содержимое рабочего стола, чтобы показать содержимое, опрашивает каждый файл, для бинарников и ярлыков — выдергивает иконку, спрашивает про UAC, для неисполняемых файлов — лезет в реестр, спрашивает где взять иконку, лезет за иконкой. На всё это тратятся циклы процессора и операции дисковой подсистемы, что, есстественно задерживает время до «комп загрузился и можно работать».
Другой вопрос что если файлов немного, то задержка вряд ли осязаема (если сравнить с чистым столом без файлов), но вот если понакидать FullHD видюшек штук 40, пару сотен фоток по 15 Мб каждая, да приказать системе не создавать Thumbs.db, то да, загрузка ощутимо замедлится на генерацию превьюшек.
Когда explorer Загружается, он показывает рабочий стол, чтобы показать содержимое рабочего стола, чтобы показать содержимое, опрашивает каждый файл, для бинарников и ярлыков — выдергивает иконку, спрашивает про UAC, для неисполняемых файлов — лезет в реестр, спрашивает где взять иконку, лезет за иконкой. На всё это тратятся циклы процессора и операции дисковой подсистемы, что, есстественно задерживает время до «комп загрузился и можно работать».
Другой вопрос что если файлов немного, то задержка вряд ли осязаема (если сравнить с чистым столом без файлов), но вот если понакидать FullHD видюшек штук 40, пару сотен фоток по 15 Мб каждая, да приказать системе не создавать Thumbs.db, то да, загрузка ощутимо замедлится на генерацию превьюшек.
«Обои-ня» для FullHD разрешения увеличивает время загрузки гораздо больше чем эти ярлычки )
Sign up to leave a comment.
Процесс загрузки Windows или что спрятано под стартовым логотипом