Миграция на 64хбитную версию (Потенциательные грабли оной)

[radial]

С 2Гб оперативы профит определенно есть. С 4мя- проще PAE. >4Гб - уже есть смысл.
Скоро- не издохнет.

[Bizdelnick]

С 2Гб оперативы профит определенно есть.

Конкретизируйте.

[radial]

оперативной памяти 32-х битной системе надо меньше => больше остается для приложений, с которыми опять аналогично.

[Bizdelnick]

Сомневаюсь, что там и 10% экономии будет. С другой стороны - прирост производительности на x86_64, хоть и не очень большой. Так что никаких явных выгод не вижу.

[Sleeping Daemon]

встречный вопрос - сколько у Вас оперативы?
у меня к концу месяца будет 4Гб.

ха-ха. x86 будет видеть 3 с чем-то там Гб. вы установите x86-64, которая будет видеть все 4Гб, но сама (и приложения) использует оперативы на 10-15% больше 32х-битной системы. В итоге то на то и выйдет. Профит? разве что "модно и молодежно", гыг))

вот если бы речь шла о 8Гб, к примеру..

x86 будет видеть не 3 с чем том, а 4 гига. И 8 будет видеть. И 64 то же...

[Deo]

Linux использует следующие дескрипторы сегментов:
Сегмент кода ядра
Сегмент данных ядра
Сегмент кода пользователя
Сегмент данных пользователя
Сегмент TSS
Сегмент LDT по умолчанию
Рассмотрим детально каждый из них.
Дескриптор сегмента кода ядра в GDT имеет следующие значения:
Base = 0x00000000
Limit = 0xffffffff (2^32 -1) = 4GB
G (флаг единицы сегментирования) = 1 для размера сегмента, выраженного в страницах
S = 1 для обычного сегмента кода или данных
Type = 0xa для сегмента кода, который можно прочитать и выполнить
Значение DPL = 0 для режима ядра
Линейный адрес для этого сегмента равен 4 GB. S =1 и type = 0xa обозначают сегмент кода. Селектор находится в регистре cs. Доступ к соответствующему селектору сегмента в Linux осуществляется через макрос _KERNEL_CS.
Дескриптор сегмента данных ядра имеет аналогичные значения за исключением поля Type, значение которого установлено в 2. Это указывает на то, что сегмент является сегментом данных и селектор хранится в регистре ds. Доступ к соответствующему селектору сегмента в Linux осуществляется через макрос _KERNEL_DS.

отсюда

Как видим, ограничение 4Гб накладывается структурой глобальной таблицы дескрипторов при работе процессора в защищенном режиме... т.е. фактически самой x86 архитектурой. так что увы

и дальше наша догадка подтверждается:

Зона верхней области памяти появилась в системе управления памятью ядра тогда, когда были реализованы расширение виртуальной памяти Pentium II (для доступа к 64 GB памяти средствами PAE - Physical Address Extension - на 32-битных системах) и поддержка 4 GB физической памяти (опять же, на 32-битных системах). Эта концепция применима к платформам x86 и SPARC. Обычно эти 4 GB памяти делают доступными отображение ZONE_HIGHMEM в ZONE_NORMAL посредством kmap(). Обратите внимание, пожалуйста, на то, что не желательно иметь более 16 GB RAM на 32-битной архитектуре даже при разрешенном PAE.

[Minton]

---

[Deo]

был неправ. Памяти стало 8Gb и система с ядром 2.6.34.7-0.7-desktop видит 7.8.
Открывая тучу тяжелых фоток в Gimp, добил потребление памяти до 4.1Гб без слива ее в своп
Видимо что-то недопонял.

УПД
А вот и ответ 32-битная адресация более 4-х Гб памяти

ну и в википедии про 36битную адресацию нашел немного
Стыдно, но не знал.
Выходит 32хбитное desktop ядро ее поддеживает?

[zenwolf]

Выходит 32хбитное desktop ядро ее поддеживает?

Обычное не поддерживает, про PAE писали уже выше.

[Lazy_Kent]

Раз уж тему подняли, отпишусь.
Обновил openSUSE 11.1 i586 на 11.3 x86_64. Обновлялся с NET iso. Никаких проблем. Показалось, что быстрее работать стала. Расчётами потребления памяти не заморачивался.

[Deo]

Обычное не поддерживает, про PAE писали уже выше.

то есть PAE - это и есть с 36битной адресацией?

тогда совсем непонятно, как объяснить

Код: Выделить всё

deo@Jah:~/Aptana Studio 3 Workspace/testPython/src> uname -r
2.6.34.7-0.7-desktop
deo@Jah:~/Aptana Studio 3 Workspace/testPython/src> free
             total       used       free     shared    buffers     cached
Mem:       8230236    3037892    5192344          0      90660    2135660
-/+ buffers/cache:     811572    7418664
Swap:       524284          0     524284

Раз уж тему подняли, отпишусь.
Обновил openSUSE 11.1 i586 на 11.3 x86_64. Обновлялся с NET iso. Никаких проблем. Показалось, что быстрее работать стала. Расчётами потребления памяти не заморачивался.

я на прошлой странице излагал свой опыт (обновлял на работе 11.3 с x86 на _64). В целом да, работает шустрее, но при запущенных под Гномом Thunderbird, FF, Chrome, и Virtual Box лагает ощутимо (оперативы 2Gb)

[Deo]

модеры, выделите в отдельную ветку пожалуйста. Что-нибудь типа "адресация 32хбитных систем"
итак. Робачевский утверждает, что
1. для 32 битной архитектуры вируальное адресное пространство процесса составляет 4Гб, из них старший 1 Гб начиная с C0000000h резервируется под ядро
при этом все сегменты получают сразу максимально возможный размер, т.к. используются только возможности страничной адресации

2. трансляция виртуальных адресов в физический осуществляется так:
виртуальный адрес в формате "индекс сегмента | смещение" транслируется в виртуальный адрес в формате "индекс таблицы страниц | индекс страницы | смещение" и далее в физический адрес
размер таблицы индексов страниц - 1024 элемента
число элементов в таблице страниц - 1024 элемента
размер одной страницы - 4Кб (но архитектура Intel 32 так же поддерживает 4 Мб)

отсюда вывод: физически адресуемо также 1024*1024*4Кб = 4Гб

не очень понятно, как у меня получилось вот такое на 32хбитной системе без PAE после того, как я воткнул 8гиг

Код: Выделить всё

deo@Jah:~/Aptana Studio 3 Workspace/testPython/src> uname -r
2.6.34.7-0.7-desktop
deo@Jah:~/Aptana Studio 3 Workspace/testPython/src> free
             total       used       free     shared    buffers     cached
Mem:       8230236    3037892    5192344          0      90660    2135660
-/+ buffers/cache:     811572    7418664
Swap:       524284          0     524284

и диспетчер процессов тоже бодро показывал, что занято памяти 4,1Гб и пустой своп когда я наоткрывал несколько десятков окон в Gimp