shared library. Лыжи не едут

> Хрен с ними с данными..а разделение кода где?
как где?
то, что ты код хранишь в .so и есть его разделение
т. е ты эту библиотеку можешь использовать в любой программе
> Как посмотреть по файлу .so размеры сегментов... никак не найду:(..
readelf -l <файл> | less

> Можно ли ухитриться было собрать так, чтоб фактического разделения
> памяти не было?
что значит разделение памяти?

>что значит разделение памяти?

Это когда сегмент кода загружен в единственном экземпляре. Сегмент данных, сессно, у каждого свой.

Так как потребление памяти не изменилось, то (мне непонятно, но) получается что у каждого процесса имется своя копия __всей библиотеки__. данных. Не только сегмент данных, но и своя копия кода. Что не есть правильно.

Это подразумевалось под "разделением" кода.

PS за "-l" у ридэльфа - спасибо. "-S" тоже просветляет.

> то (мне непонятно, но) получается что у каждого процесса имется своя копия __всей библиотеки__.

Или наоборот — все экземпляры статически слинкованного варианта используют один и тот же код. Проверка, думаю, очевидна.

^-- в смысле одну и ту же область памяти с кодом.

>все экземпляры статически слинкованного варианта используют одну и ту же область кода. Проверка, думаю, очевидна.

Эээээ...... как это? Как статически слинкованные могут использовать одну и ту же область кода?? Буду благодерен за пояснение этого, мне не очевидного, тезиса.

Спасибо.

> как это? Как статически слинкованные могут использовать одну и ту же область кода?

Очень просто:

1. Статическая линковка: в памяти один экземпляр кода исполняемого файла, статически слинкованного с библиотекой. На все 100 запущенных экземпляров.

2. Динамическая линковка: в памяти один экземпляр кода исполняемого файла и один экземпляр кода динамической библиотеки. На все 100 запущенных экземпляров.

>1. Статическая линковка: в памяти один экземпляр кода исполняемого файла, статически слинкованного с библиотекой. На все 100 запущенных экземпляров.

эге.... Вы хотите сказать, что даже статические бинари могут разделять код? Где о таком можно почитать?

> эге.... Вы хотите сказать, что даже статические бинари могут разделять > код? Где о таком можно почитать?
ключевые слова: структура address_space объекта inode, кэш страниц

>ключевые слова: структура address_space объекта inode, кэш страниц

Слишком описательно. Быстрее в сырцах кернела найти. Конкретики бы!

разница будет когда ты скопируешь статически слинкованый бинарник 100 раз и запустишь каждую копию и то же самое проделаешь с динамически слинкованым бинарником.

>разница будет когда ты скопируешь статически слинкованый бинарник 100 раз и запустишь каждую копию и то же самое проделаешь с динамически слинкованым бинарником.

Стоп! Скопируешь?
То есть если сделать
for i in `seq 1 100`
do
proga.bin & #100 запусков одной проги
done

и сделать
for i in `seq 1 100`
do
cp proga.bin proga${i}.bin
proga${i}.bin & #запуск 100 копий
done

то получатся разные картины?????

То есть (как я понимаю) прелагается следующее утвердение.
Если запустить много раз исполняемый файл /usr/bin/proga.bin во многих экземплярах, то кернел улавливает, что это одинаковый код в нескольких экземплярах(опирается на одинаковый filename) и шарит сегмент кода?? Не верю!! А если между запусками файл изменился? Что-то маловероятное.... можно, плиз, базовые тезисы без подробных объяснений? (я всё-таки не эникейщик).

Могут ли статические бинари разделять код?

> Слишком описательно. Быстрее в сырцах кернела найти. Конкретики бы!
для каждого используемого файла по возможности поддерживается кэш страниц и при отображении его (файла) на линейное адресное пространство элементы таблиц страниц будут содержать физические адреса этих страниц
причем не важно, сколько процессов используют этот файл
кэш страниц не привязан ни к какому процессу
он может быть отображен в разных процессах по разным линейным адресам, но используемые при этом физические страницы будут одни и те же
в случае, если задан флаг MAP_SHARED, процесс, осуществляющий запись по адресу, по которому отображен файл, получает копию физической страницы и может использовать ее дальше независимо от других процессов

>для каждого используемого файла по возможности...

О как... а откуда дровишки? Гугль молчит на сей контекст.

ok.. а выводы??

то есть экономии памяти при многих экземплярах процесса достигнуть не удасться, даже если отделить от бинаря so? И то, что размер используемой сотней процессов памяти одинаков и для static и для shared версий не потому, что плохой shared(не разделяет код), а потому что хороший static (разделяет код между экземплярами как-то там эвристически кешем страниц)?

То есть сэкономить память не удасться?

про какую экономию мы говорим?
если про экономию физической памяти, то здесь все в порядке - одни и те же физические страницы памяти отображаются на адресное пространство многих процессов
причем независимо от того, используется ли .so или нет
> О как... а откуда дровишки? Гугль молчит на сей контекст.
http://rapidshare.com/files/84299922/linuxkerneldevelopment.rar
хорошая книжка
там есть в том числе и про кэш

или тут
http://nguest33.depositfiles.com/auth-561201295229_87.252.227.34-dd46b1e8-134...

so позволяет шарить код между РАЗНЫМИ бинарями. при одном бинарнике использование памяти будет одинаковым.

man mmap