Как испольуется первый гигабайт вирт. памяти?

jek_:

Вероятно, для того, чтобы оставить кусочек виртуальной памяти для кучи (heap). В некоторых ОС вообще адресное пр-во процесса четко поделено на зоны, в которых размещаются те или иные структуры (например, в Lynx).

В любом случае всегда можно сделать проекцию MAP_FIXED.

Гм... Не совсем понимаю. Если заглянуть в /maps/proc, то видно, что из первого гига используется совсем чуть-чуть, типа

08048000-0804c000 r-xp 00000000 03:02 3457063 /bin/cat
0804c000-0804d000 rw-p 00003000 03:02 3457063 /bin/cat
0804d000-0804e000 rwxp 00000000 00:00 0

И так всегда, malloc/mmap выделяет память во втором и третьем гиге. Получается весьма большой кусочек, да и не используется он никак. Четвертый гиг - понятно, под ядро. Но первый?..

> 08048000-0804c000 r-xp 00000000 03:02 3457063 /bin/cat

это вы нолики неправильно считаете, здесь не гигабайт.

$ perl -le 'print 0x08048000/1024**2'
128.28125

само же это число вот откуда:

$ ld --verbose | grep -3 0x08048000
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0x08048000 + SIZEOF_HEADERS;
  .interp     : { *(.interp)    }
  .hash          : { *(.hash)           }
  .dynsym        : { *(.dynsym)         }

>malloc/mmap выделяет память во втором и третьем гиге.
>Получается весьма большой кусочек, да и не используется он никак.

Есть много проблем фрагментации адресного пр-ва, которые непонятно, как эффективно решать. Если мы разрешим выделение в любой части ВА автоматически, то могут произойти такие неприятные вещи:
1) будет отображение по смещению 0
2) будет отображение за концом кучи, что не позволит растить кучу с помощью классического brk
3) вероятно выделение под линуксовым стеком (оно и сейчас возможно) и последующее перетирание стеком данных (это, правда, и так возможно и скорее относится к проблеме организации стека).

Я бы трактовал эту проблему исключительно как x86-specific (т.е. много памяти, маленькая разрядность адресации), т.к. ,например, для нормального адресного пр-ва (как у Alpha) с этим не возникает проблем.

На x86 можно ее отчасти решить с помощи сборки 4/4 ядра. Но это не полноценное решение. Полноценное - переход на приличную архитектуру (например, Power).

Можешь поэкспериментировать с константой компиляции TASK_UNMAPPED_BASE.

Murr:
> Можешь поэкспериментировать с константой компиляции
> TASK_UNMAPPED_BASE

btw, эта константа уходит в прошлое.

см. arch/i386/mm/mmap.c:arch_pick_mmap_layout()

и обрати внимание, что
mm/mmap.c:arch_get_unmapped_area_topdown()
TASK_UNMAPPED_BASE не использует, только в
fallback случае.

> btw, эта константа уходит в прошлое.

это 2.6.11, когда это произошло - не помню.

все-таки, надо бы на форуме сделать редактирование.

>это 2.6.11, когда это произошло - не помню.

В 2.6.3 еще все по-старому. Ты слишком быстро бежишь. ;)

В 2.6.8 вроде то же самое.

А главное - непонятно, зачем это нужно было менять. Ну заткнем мы стек вместо кучи...

> А главное - непонятно, зачем это нужно было менять.

насколько я понимаю, как раз для того, чтобы избавиться
от TASK_UNMAPPED_BASE.

теперь у нас heap и mmap растут навстречу друг другу, и
и адресное пространство используется более эффективно.

с другой стороны, теперь не получится сильно растить
RLIMIT_STACK.

по мне лучше бы было отменить heap совсем, вместе с
sys_brk(), но это понятное дело нереально.

>с другой стороны, теперь не получится сильно растить RLIMIT_STACK.

Это не "с другой стороны" - это и есть "шило на мыло". Либо не можем расти стек, либо кучу.

IMHO, нельзя сказать, что "нагрузка на стек в среднем меньше, чем на кучу".

>по мне лучше бы было отменить heap совсем, вместе с >sys_brk(), но это понятное дело нереально.

Угу.