Ну почему же, вот новый альфа-лев в прайде чаще всего первым делом убивает всех детей своего предшественника. Не говоря уже о всяких мелочах типа войн на уничтожение из-за разного состава феромонов (у позвоночных не слишком популярно, но у насекомых, которые тоже относятся к царству животных, — кругом). Это даже не расизм — это геноцид на основе запаха.
В общем да, не стоит примерять мораль вида человек разумный на другие виды. Как в одну, так и в другую сторону.
Пытался отследить как работает MAP_ANONYMOUS и в конце концов потерялся в логике обработки фолтов на hugetlb файлах (тяжело без нормального kernel debugger-а). Ни документация ни комментарии не упоминают, что MAP_ANONYMOUS не чарджит коммит (в комментариях только указано, что у hugetlb собственный аккаунтинг и поэтому системный использоваться не будет).
В любом случае, я уже сдался и поверил, что 100терабайтные файлы в линуксе мепить можно. Это просто невообразимо круто :-)
А это смотря где. Не знаю как в линуксе, а винда деманд-пейджит. То есть bss будет закоммичен, а страницы туда будут вставляться из zeroed list-а по мере доступа.
Но ведь если его выключить, то не получится мепить 100терабайтные секции — как же с этим жить? Ну и еще всякие мелочи типа гениального изобретения — форка, из-за которого требования к памяти (закоммиченной — не физической) будут в несколько раз превышать реальные (в большинстве случаев, ага).
Да нет там бага. Никто и никогда не гарантировал, что будет доступен непрерывный кусок размеров в четверть адресного пространства. Best effort, все дела.
> Физическую память дефрагментировать не нужно
это кому как.
Единственный случай, когда нужны куски непрерывной физической памяти — это DMA без поддержки scatter/gather. Может я упускаю из виду что-то важное? Напомните, пожалуйста.
и я о том же. Пилить и пилить.
Нет, серьезно, на хрена вы писали манифест, если не собираетесь придерживаться своих же деклараций. Напомню
2) Судить имеет право тот, кто разбирается в предмете. Иногда лучше жевать.
Управляемые языки еще могут двигать кучу туда-сюда, но вторичная трансляция здесь ни при чем, и любые манипуляции с адресным пространством, не запрошенные напрямую рантаймом этих языков МГНОВЕННО вызовет AV в этом самом рантайме и процесс умрет мучительной смертью.
Если под сервером Вы имели в виду IIS, то возможность существует уже очень давно. В общем случае потребление памяти процессом (и/или группой процессов) в винде ограничивается при помощи Job Object-ов. Это если процесс недоверенный и не только менять, но и знать о своих лимитах. Если же достаточно более «мягких» ограничений (читать можно, для увеличения нужна SeIncreaseWorkingSetPrivilege) и нельзя контроллировать сразу группу процессов (включая всех «детей»), то можно воспользоваться SetProcessWorkingSetSizeEx (в дотнете это Process.MaxWorkingSet)
Какую фишку? Обеспечить гарантированную возможность выделения 512 метров одним куском на 32-битной системе? А если приложение линкуется с dll-ками, базированными через каждые 400 метров и без релоков? А если нужно не 512, а 768 — откуда вообще взялось магическое число 512?
Например, пусть оно запустит дефрагментатор физической памяти, подвигает адреса в виртуальной и сделает последовательный блок.
Вы реально абсолютно не понимаете происходящего, но при этом выступаете с заявлениями. Физическую память дефрагментировать не нужно — адресное пространство можно «дефрагментировать» простой перенастройкой таблиц/директории страниц для процесса. Вот только с вероятностью около единицы ни один процесс подобного не переживет.
что будет, если запустить .NET'овский сервер на виртуалке? Пипец придет виртуалке. У него даже ограничителя памяти нету как в жаве.
Слова не мальчика но иксперта. Всего доброго
SLAT существует, но в данном случае он абсолютно не решает проблем фрагментации адресного пространства (при этом решает другие — в частности оверхед на сброс TLB кешей при переключении VM контекстов): для того, чтобы пересобрать физические страницы в любом порядке второй уровень трансляции не нужен, но любая пересборка адресного пространства просто «сломает» все указатели, которые хранит код в данном адресном пространстве.
Не вставляет. Просто не стоит рассчитывать, что можно выделить четверть всего доступного адресного пространства одним куском в любых условиях даже если В БОЛЬШИНСТВЕ случаев это возможно. На любой системе.
И? Вы знаете зачем оверкоммит введен? Почему несмотря на всю тупость его использования он до сих пор включен по дефолту? Серьезно, из-за жопорукости линукса (хотя конкретно здесь руки растут из жопы оригинальных дизайнеров юникса) Вы вот таким оригинальным образом напрашиваетесь на еще большие проблемы, чем OOM Killer (хотя сложно себе такое представить, да).
Ну так и грузит же. Вы проверьте, да. То что на ОДНОЙ системе kernelbase.dll вылез куда не следует как раз и говорит, что на всех остальных он сидит там, где ему и положено — в районе 0x70000000:
0:000> lmm kernelbase
start end module name
76110000 761b2000 KERNELBASE (deferred)
Ну да, а Линукс значит поддерживает. Проверяли? Или та же история, что и со 100500 ядрами — обнаруживаем (тоже чисто теоретически), значит поддерживаем, а что глобальные локи до сих пор используют (то что BKL в 2011 наконец выпилили — это, конечно, хорошо, но RCU все еще глобальный — просто неэкслюзивный, как BKL) — так это ничего — на РЕАЛЬНУЮ поддержку многоядерности оно совершенно не влияет.
В общем да, не стоит примерять мораль вида человек разумный на другие виды. Как в одну, так и в другую сторону.
В любом случае, я уже сдался и поверил, что 100терабайтные файлы в линуксе мепить можно. Это просто невообразимо круто :-)
Единственный случай, когда нужны куски непрерывной физической памяти — это DMA без поддержки scatter/gather. Может я упускаю из виду что-то важное? Напомните, пожалуйста.
Нет, серьезно, на хрена вы писали манифест, если не собираетесь придерживаться своих же деклараций. Напомню
Управляемые языки еще могут двигать кучу туда-сюда, но вторичная трансляция здесь ни при чем, и любые манипуляции с адресным пространством, не запрошенные напрямую рантаймом этих языков МГНОВЕННО вызовет AV в этом самом рантайме и процесс умрет мучительной смертью.
Вы реально абсолютно не понимаете происходящего, но при этом выступаете с заявлениями. Физическую память дефрагментировать не нужно — адресное пространство можно «дефрагментировать» простой перенастройкой таблиц/директории страниц для процесса. Вот только с вероятностью около единицы ни один процесс подобного не переживет.
что будет, если запустить .NET'овский сервер на виртуалке? Пипец придет виртуалке. У него даже ограничителя памяти нету как в жаве.
Слова не мальчика но иксперта. Всего доброго
echo fffffffuuuuuu >/proc/sys/vm/overcommit_memory
А с
echo 5 >/proc/sys/vm/overcommit_memory
Как мне отловить ошибку и откуда вообще взялась идея о том, что парсинг строк — это хороший метод работы с настройками?
PS: Вы видимо имели в виду «echo 2 ...», потому как 0 все еще оверкоммитит