Изпечатай

[astronom]

Не мога да разбера защо на една машина наличната памет в Linux е доста под наличната физическа. Машината е нова:

Дъно: Gigabyte EG43M-S2H
Процесор: Intel Pentium Core 2 Duo E5200 2.5 GHz
Памет: A-DATA 2x2GB DDR2 800MHz
Дистрибуция: Slackware Linux 12.1
Ядро: 2.6.24.5 (стандартното с поддръжка на smp и highmem4g)

Примерен код

$ zcat /proc/config.gz | grep X86_SMP CONFIG_X86_SMP=y $ zcat /proc/config.gz | grep HIGHMEM # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y

BIOS правилно разпознава наличната физическа памет. След стартиране в dmesg имам:

Примерен код

Memory: 3065856k/4194304k available (6059k kernel code, 42744k reserved, 2015k data, 380k init, 2192256k highmem)                           virtual kernel memory layout:                                                                                                                   fixmap  : 0xffe15000 - 0xfffff000   (1960 kB)                                                                                               pkmap   : 0xff800000 - 0xffc00000   (4096 kB)                                                                                               vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)                                                                                               lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)                                                                                                 .init : 0xc08ed000 - 0xc094c000   ( 380 kB)                                                                                                 .data : 0xc06eadca - 0xc08e2cfc   (2015 kB)                                                                                                 .text : 0xc0100000 - 0xc06eadca   (6059 kB)

И не мога да разбера, защо са достъпни само 2,92 ГБ? Знам, че е писано по темата, търсих информация и в Инет. Ясно ми е, че системата може да е разервирала някаква памет, която не може да се ползва от операционната система, но все пак това е цял един ГБ.

Моля, за вашите съвети/помощ.

[teleport]

Сетни и CONFIG_X86_PAE=y и ще видиш цялата памет.

[remotex]

Ето едно добро обяснение. Понякога обновяването на БИОС (и ровичкането из новите му възможности след това също помага)
Дааа - много яките видео карти понякога пречат: особено в комбинация със старо дъно/БИОС '>
Успех!

[teleport]

Това обяснение е тъпо и не е вярно:

Цитат

If you install 4Gb, there is no way to make all of the RAM between 3Gb and 4Gb available without installing a 64-bit OS, which you can't do unless you have a 64-bit CPU. And even then it won't necessarily work. So, to avoid hassles on current systems, it's best to stick with 3Gb or less.

32 битово ядро без проблем адресира 64Gb адресно пространство използвайки PAE технологията, която присъства още от Pentuim PRO процесорите.

Без PAE ядрото адресира 4Gb. Само че никой не казва 4Gb RAM, а 4Gb адресно пространство. В него се намира и паметта на видеокартата, pci/pcie контролерите и т.н. Има bios-и които просто заделят пространството от 3 до 4G за IO карти, без значение дали контролерите ги има изобщо или не. Останалата 1Gb памет се премества в адресното пространство от 4 до 5G и съответно без PAE не може да бъде адресирана.

Малко повече за PAE във wikipedia

[astronom]

Цитат (teleport @ Окт. 02 2008,07:16)

Сетни и CONFIG_X86_PAE=y и ще видиш цялата памет.

Добре, ще пробвам, но не би ли трябвало да не е необходимо PAE? В смисъл само ако искам повече от 4 ГБ с 32 битова операционна система. Защото имам една друга машина дето e със същата конфигурация на ядрото и е стара (на повече от 5 години). Тя без проблем си разпознава пълната налична физическа памет от 3.5 ГБ (512 МБ + 1 GB + 2x1 GB). Затова ми е старано, че новата има проблем.

Между другото boot-нах със Slamd64, който е с 64 битово ядро и то ползва 3,78 ГБ. Това по-бих го разбра ако става въпрос за резервирана от системата памет...

[teleport]

Цитат

Дъно: Gigabyte EG43M-S2H

Дъното ти има вградено видео ( Intel GMA X4500 ) което взима видео памет от системната.

[gat3way]

@teleport, не е тъпо и е вярно ама от гледна точка на адресното пространство на процеса, а не от гледна точка на утилизирането на физическата памет въобще.

Значи физическата памет на 32-битова архитектура директно може да се адресира само до 1-вия гигабайт. Тъй като се "отцепват" 128 мегабайта за мапиране на по-горна памет, всъщност се адресират до 896 мегабайта физическа памет. По дефолт, ядрото може директно да адресира и до 1ГБ виртуална памет.

Когато си с CONFIG_HIGHMEM можеш да мапираш "горната" памет и тогава дефакто примерно ако имаш 1ГБ физическа РАМ  можеш да използваш и последните 128 мегабайта, мапирайки ги при желание върху "долните" 896 мегабайта. С PAE (CONFIG_HIGHMEM64) можеш да мап-ваш до 64 гигабайта памет (но не и директно да я адресираш и достъпваш, има едни таблици, те пазят кои страници от горната памет върху кои адреси от долната се мап-ват). Това от гледна точка на ядрото.

От гледна точка на адресното пространство на процеса, може да се адресират до 4 гигабайта, независимо от режима. Тази памет се цепи на страници (по 4кб обикновено) и тези страници се мапират или върху физическата памет, или върху суоп-а. За целта всеки процес си има pagetable, първите 128 мегабайта от адресното пространство на процеса обикновено, затова програмния код се зарежда от 0х08048000 нагоре. Ако процесът достъпи памет, мапирана върху суоп-а се случва page fault, процесът се прекъсва и ядрото вади страницата от диска и я слага във физическата памет, променя мапировката, така че за процеса тази памет е на същия адрес, но дефакто се намира другаде.

Сега защо процесът може да ползва до 3ГБ, въпреки че адресира до 4ГБ? Ами просто. В адресното пространство на процеса се мап-ва цялото виртуално адресно пространство на ядрото (1ГБ както казах). Повечето от тази памет не може да се чете, страниците са маркирани без атрибут "r" и достъпването им води до segmentation fault за програмата.

Има варианти това да изглежда по различен начин, примерно виртуалното адресно пространство на ядрото може да се увеличи до 2ГБ. Тогава обаче процесът вече като го мап-не може да използва само 4-2=2ГБ памет. Това се нарича 2G/2G split и може да бъде полезно ако примерно имаш много натоварен рутер дето прави QoS и в същото време нямаш работещи процеси дето да изискват много памет. С това трябва да знаеш че със сигурност ще разкажеш играта на всички java виртуални машини, wine и други неща дето имат навика да резервират цялата си възможна памет и да си правят собствен мениджмънт на паметта, уповавайки се на това, че ако имат възможност, ще адресират до 3ГБ памет.


Но да, в най-добрият случай на 32-битова архитектура, реално погледнато един процес може да задели максимум 3ГБ памет. Иначе може да адресира и евентуално чете максимум 4ГБ. Със или без PAE, това няма значение.


Апропо, нещата с 64-битовите архитектури стоят по подобен начин, просто там лимитите са много по-големи, затова 3G/1G split-а изобщо не ти прави проблеми, дори да имаш 512 гигабайта физическа памет.

[teleport]

@gateway: тъпото и невярното е цитата, които съм постнал. Няма никакъв проблем 32 битов кернел(!) да адресира 64Gb когато работи върху 32 битов процесор. В цитата се твърди че няма начин да използваш над 3Gb без да имаш 64 битова OS, естествено работеща върху 64 битов процесор, което не е вярно. Pentium PRO има физически 36 адресни шини и може да адресира физически 2^36 адресно пространство (64Gb).

Никъде не съм споменал процес. Абсолютно съм съгласен че 32 битов процес може да адресира директно 4Gb, въпреки че има начини да адресира и повече. Ставаше въпрос само за кернела.

В конкретния случай печалбата от PAE кернел ще е малко над 512Mb физическа рам. 128 трябват за PAE таблиците , още 128 ще вземе вграденото видео, bios-а ще задели още малко за кеширане.

Ползата от PAE е много осезаема при повечко рам. Примерно при мене поради работни съображения трябва да съм на 32bit OS. Резултата с инсталирани 8Gb рам е:

$ cat /proc/meminfo
MemTotal:      8240892 kB
MemFree:         30192 kB
Buffers:        503920 kB
Cached:        7029568 kB
SwapCached:          0 kB


128M са PAE таблици, 16Mb е отделил bios-а, останалите са използваеми. 7Gb от тази физическа памет са дисков кеш. Явно ядрото все пак може да адресира и използва цялата налична физическа рам? Мене това ме устройва прекрасно, особено в комбинация със свястен ups, защото съм виждал как процес създава, записва и затваря 2Gb файл, без хадовете изобщо да мигнат. Спирането на тока в тоя момент е фатално.

[Naka]

Вече 2 пъти го виждам този проблем и то на 64 битови intel процесори и 64 битов линукс;
при 4 GB рам като напиша
free
съобщава само 3 GB.

[gat3way]

Ми не, няма начин да адресираш повече от 4ГБ, но можеш да ползваш де, въпреки че е доста сложно. Първо създаваш един достатъчно голям файл, примерно 10ГБ, след това mmap() ваш региони от него (с MAP_PRIVATE | MAP_FIXED), когато ти трябва друга памет, munmap()-ваш това и захапваш друг регион, буферът ти си е на едно място, но това, което съдържа е различен регион от големия файл. Обаче това по принцип е доста сложна за изпълнение работа, понеже зависи от много неща и поради това се прави рядко.

Но дефакто, същата схема става и с т.нареченият HIGHMEM, значи там (опростено погледнато) имаш 128 мегабайтов да го наречем буфер, който се намира от 896-тия до 1024-тия мегабайт. Ако искаш да изчетеш примерно 128 мегабайта от 3096-тия до 3224-тия мегабайт, съответно тези горни 128 мегабайта се мап-ват върху нашите (896-1024). Логически е абсолютно сходна операция.

Но и в двата случая не се адресира пряко тази памет. В случаят с mmap() няма как да адресираш всички offset-и от началото на файла и когато ти скимне директно да изчетеш данните от еди кой си offset, може да се наложи първо да munmap()-ваш и да mmap()-ваш правилния регион. И по същият начин стои въпроса с физическата памет, там директно не можеш да адресираш някакъв адрес от паметта над 1ГБ. Първо тази страница съдържаща този адрес се мап-ва някъде в този 128-мегабайтов да го наречем "буфер" и тогава четеш. Линейно не можеш да четеш над 1-вия гигабайт, но въпреки това можеш да четеш оттам (от виртуалната де, не физическата памет). Пейджинг-а се грижи това което четеш да се намира във "високата" памет и да ти бъде достъпно.

[gat3way]

@Naka, съобщава щото му е тъп БИОС-а и резервира памет за I/O операции с хардуера. Линукс вижда тва, което му остане след като мине БИОС-а. Ако има начин да се забранява това (MMIO region blabla или нещо от сорта) в БИОС-а или пък да се разреши memory remap-a, тогава ще се виждат 4-те гигабайта. Ако няма сигурно е гадно '> Това не зависи от дистрибуцията дали е 32/64-битова или от това дали се ползва или не PAE.

[astronom]

Цитат (teleport @ Окт. 02 2008,07:16)

Сетни и CONFIG_X86_PAE=y и ще видиш цялата памет.

Да, по този начин успях да ползвам 3,92 ГБ (най-много).

Въпросът е сега дали да си сложа 64 битова операционна система или да си остана с 32 битова с оглед на това, че в бъдеще мисля да добавя още памет...

Резултати с ядро 2.6.24.5 (32bit, SMP): 2.92 GB

Примерен код

MemTotal:      3067008 kB

Резултати с ядро 2.6.24.5 (32bit, SMP, PAE): 3.92 GB

Примерен код

MemTotal:      4107372 kB

Резултати с ядро 2.6.24.5 (64bit, SMP): 3.81 GB

Примерен код

MemTotal:      4004096 kB

[Naka]

Цитат (gat3way @ Окт. 02 2008,23:15)

@Naka, съобщава щото му е тъп БИОС-а и резервира памет за I/O операции с хардуера. Линукс вижда тва, което му остане след като мине БИОС-а. Ако има начин да се забранява това (MMIO region blabla или нещо от сорта) в БИОС-а или пък да се разреши memory remap-a, тогава ще се виждат 4-те гигабайта. Ако няма сигурно е гадно '> Това не зависи от дистрибуцията дали е 32/64-битова или от това дали се ползва или не PAE.

И 1 GB за I/O операции с хардуера? трябва наистина де е много тъпо!

Как се казва тази опция в биоса,  щото нищо подобно не съм виждал?

като бутваше кърнела видях няколко реда от сорта:
mttr remapping ......
mttr remapping ......
..
това има ли нещо общо?

[gat3way]

Ами наистина е много тъпо, но е факт. Иначе това съобщение нищо не ми говори, не знам. Що се отнася до опцията в БИОС-а нямам идея как точно трябва да се казва при теб и дали ще я има. Трябва да е нещо от сорта на memory remapping, или пък нещо от сорта на io memory region hole ..., не знам как са го дефинирали. А и може и да няма такава опция, което е лошо. Ако няма, виж дали ако го флашнеш с по-нова версия няма да се появи. Ако не - кофти.

Чак за 1 ГБ може би наистина е много, случаят, който аз съм виждал беше с 512 мегабайта отново с 4ГБ рам. Нито уиндоус, нито линукс можеха да ги ползват, накрая се оказа че проблемът е в БИОС-а.

[tarator]

mtrr няма нищо общо с memory mapping-a.