Каково различие между 32-разрядным PAE и 64-разрядными ядрами?
Необходимо проверить, тратятся ли большую часть Вашего времени на ЦП или во вводе-выводе. Так или иначе существуют способы улучшить его:
A: не сжиматься
Вы не упоминали "сжатие" в своем списке требований, так попытайтесь отбросить "z" из своего списка аргументов: tar cf. Это могло бы быть, ускоряют вещи немного.
Существуют другие методы к ускорению, которое регистрирует процесс, как использование "-N" для пропуска, Вы уже создали резервную копию прежде.
B: скопируйте целый раздел с dd
С другой стороны, если Вы создаете резервную копию всего раздела, делаете копию целого образа диска вместо этого. Это сохранило бы обработку и много времени поиска головки диска. tar и любая другая программа, работающая в более высоком уровне, имеет издержки необходимости читать и записи рабочего каталога и inodes для нахождения, где содержание файла и сделать больше главного поиска на диске, читая каждый файл из различного места от диска.
Для резервного копирования базовых данных намного быстрее используйте:
dd bs=16M if=/dev/sda1 of=/another/filesystem
(Это предполагает, что Вы не используете RAID, который может изменить вещи немного),
Ядро видит физическую память и предоставляет представление процессам. Если Вы когда-нибудь задавались вопросом, как процесс может иметь 4 ГБ пространства памяти, если Ваша целая машина получила только 512 МБ RAM, вот почему. Каждый процесс имеет свое собственное пространство виртуальной памяти. Адреса в том адресном пространстве отображаются или на физических страницах или на области подкачки. Если к области подкачки, они должны будут быть подкачаны назад в физическую память, прежде чем Ваш процесс сможет получить доступ к странице для изменения ее.
Пример от Torvalds в ответе XQYZ (DOS highmem) не слишком неправдоподобен, хотя я не соглашаюсь о его заключении, что PAE обычно является плохой вещью. Это решило определенные проблемы и имеет его достоинства - но все это спорно. Например, реализатор библиотеки не может чувствовать реализацию как легкую, в то время как пользователь той библиотеки может чувствовать эту библиотеку как очень полезную и простую в использовании. Torvalds является реализатором, таким образом, он обязан сказать, о чем говорит заявление. Для конечного пользователя это решает проблему, и это - то, о чем заботится конечный пользователь.
Поскольку один PAE помогает решить другую проблему прежней версии на машинах на 32 бита. Это позволяет ядру отображать полных 4 ГБ памяти и работы вокруг дыры памяти BIOS, которая существует на многих машинах и заставляет чистое ядро на 32 бита без PAE "видеть" только 3.1 или 3,2 ГБ памяти, несмотря на физических 4 ГБ.
Так или иначе для ядра на 64 бита это - симметричное отношение между физической страницей и виртуальными страницами (оставляющий в стороне область подкачки и другие детали). Однако ядро PAE отображается между указателем на 32 бита в адресном пространстве процесса и адресом на 36 битов в физической памяти. Больше бухгалтерии необходимо здесь. Ключевое слово: "Расширенная Таблица страниц". Но это - несколько больше вопроса о программировании. Это - основное различие. Больше бухгалтерии по сравнению с полным линейным адресным пространством. Для PAE это - блоки 4 ГБ, как Вы упомянули.
Кроме этого и PAE и 64 бита допускают большие страницы (вместо стандартных страниц на 4 КБ в 32 битах).
Глава 3 Объема, 1 из Руководства процессора Intel имеет некоторый обзор и Главу 3 Объема 3 А ("управление памятью Защищенного режима") имеет больше деталей, если Вы хотите читать на нем.
Мне кажется, что это - большое различие, которое, кажется, проигнорировано многими людьми.
Вы правы. Однако большинство людей является пользователями, не реализаторами. Вот почему они не будут заботиться. И, пока Вы не требуете огромных объемов памяти для своего приложения, многие люди не заботятся (тем более, что существуют слои совместимости).
-
1Так, только чтобы быть педантичным, процесс, работающий на 32-разрядном ядре PAE, может только получить доступ максимум к 4 ГБ памяти? Это было моим основным моментом, в то время как адресное пространство расширяется, не как некоторый пожиратель ресурсов памяти приложения будет способным использовать всех 64 ГБ. Спасибо за подробный ответ, но я хочу оставить это открытым только для большего количества комментариев. – Mr. Shickadance 26.04.2011, 23:53
-
2@Mr. Shickadance: действительно. Для всех практических целей и как пользователь, это - все, что релевантно. Просто требуемый для проверки подразумевается, что существует логическое разделение между виртуальным адресным пространством и физическим адресным пространством. – 0xC0000022L 27.04.2011, 01:35
-
3@Mr. Shickadance нет, который является полностью неправильным. Процесс, работающий на 32-разрядном ядре PAE только, имеет доступ к 4 ГБ виртуальной памяти, но это может получить доступ ко всей физической памяти. PAE никогда удаляет ограничения ядра на физическую память и пространство пользователя физическая память доступа непосредственно, только ядро делает. – David Schwartz 27.11.2011, 07:06
-
4@David:верно. и даже с этим ограничением виртуального адресного пространства мы можем обмануть, пока система обеспечивает анонимные файлы с отображенной памятью. Таким образом, мы могли все еще использовать вне 4 ГБ, просто не сразу. большое спасибо – 0xC0000022L 27.11.2011, 16:41
Вы могли бы хотеть изучить то, что Linus Torwalds говорит об этом здесь:
PAE перевернул тот очень очевидный факт с ног на голову и завинтил вещи по-царски. Кто бы ни придумал идею, было полностью некомпетентно, и забыл все боли HIGHMEM DOS. Существует чертовски серьезное основание, почему мы оставили эти 286 и начали использовать 386′s, вместо того, чтобы иметь дерьмо HIGHMEM с окнами в большее физическое пространство.
[...]
Так повторение после меня: PAE ничего действительно никогда не фиксировал. Это была ошибка. Это был просто полный отказ и результат hw инженеров, не понимающих программное обеспечение.
-
1, Интересный... быть показанным код сборки HIGHMEM DOS преподавателя, я могу, по крайней мере, согласиться, что это была боль. – Mr. Shickadance 26.04.2011, 21:20