Надо было /dev/mem грепать.

печалька

@l29ah В новых ядрах нельзя же: можно только явно ммапить и только отдельные регионы. Алсо, на самом деле лиса оставляет в памяти своего процесса даже уже закрытые вкладки приватного режима (секурно, чо, я так однажды с помощбю грепа и strings свою сессию восстановила). Если 4da там ничего не нашел, то в /dev/mem тоже вряд ли найдет, разве что в видеопамяти текстуру с текстом.

чоза проебало? все формы сохраняются же, если прямыми руками сделаны.

@etw Ты так говоришь будто прыщи скремблят отжатую у юзерспейса память.

@l29ah > Ты так говоришь будто прыщи скремблят отжатую у юзерспейса память. Суть в том, что лиса даже системе память не отдает, это такая фича, потому что, например, лиса позволяет переоткрывать закрытые вкладки приватной сессии. А скремблингом у меня занимается торрент-клиент :3

А мог бы нажать назад в браузере и c-z.

@anonymous Сохраняются даже если кривыми сделаны.

да меня это тоже бесит

Бля, я ебу тупых советчиков набежало. Они долбоёб не понимает как виртуальная память работает, другой не знает как аджакс-формы устроены.

@etw Дебилушка, какой ммап? Просто нужно делать fseek по границам регионов из /proc/x/maps, иначе ядро выдаст EIO при чтении из несуществующей страницы и тот же cat просто выйдет с ошибкой. gcore это и делает как раз. Хуею с некоторые дебилов, которые даже не проверили, работают ли их советы, а уже со своим дохуя умным мнением лезут. Чтобы не оставлять надо явно затирать, как делают крипто-библиотеки. Т.к. free(3) даже системе память не отдаёт, так и остаётся в пределах памяти процесса. Какой нахуй видеопамяти? Яебу ты кукаретик.

@4da >надо еще ptrace-ом к процессу аттачнуться Зачем? Открываешь /proc/x/mem, дампишь все страницы (или только heap) из /proc/x/maps, профит. gcore просто за тебя это сделает.

@anonymous Олсо (думал ты про /proc/x/mem): https://lwn.net/Articles/267427/ https://stackoverflow.com/questions/11891979/accessing-mmaped-dev-mem https://stackoverflow.com/questions/30650054/kernel-panic-when-i-do-cat-dev-kmem Но всё равно нет смысла именно физическую память читать, аллоцированные страницы не могли из процесса уйти. Просто либо пост-формы хранятся как-то иначе (хотя пару раз обрывки так находил), либо лиса уже успела их перезатереть чем-то.

@anonymous > Дебилушка, какой ммап? Просто нужно делать fseek по границам регионов из /proc/x/maps, иначе ядро выдаст EIO при чтении из несуществующей страницы и тот же cat просто выйдет с ошибкой. Уау! // Пиздец, ты тупой, я примерно о том же и говорила, и про то, что в относительно новых ядрах нельзя считать весь /dev/mem и про регионы > gcore это и делает как раз. А ты думаешь я грепом и strings-ом по /dev/mem-у бегала (учитывая, что в первом предложении я написала, что тупо грепнуть /dev/mem нельзя), а не по core dump-у (снимала, правда, с помощью gdb, потому что gcore часть регионов пропускал)? > Т.к. free(3) даже системе память не отдаёт, так и остаётся в пределах памяти процесса. Отдает, но не всегда, только если, грубо говоря, если опустить приколюхи с чанками, на странице больше не осталось занятых процессом участков. > Какой нахуй видеопамяти? По крайней мере, когда используется для отрисовки opengl, содержимое окон рендерится в текстуры, которые при изменении флипаются, и старые кадры некоторое время еще остаются в видеопамяти. С 2D ускорением хз, надо в видеодрайверы и реализацию рендеринга смотреть.

@4da Совсем нет или прост не используется?

@4da Лан

@anonymous чмафки

@etw strings+grep хуита, кстати, часто UTF8-текст кусками в памяти лежит и фигово так искать/доставать результа. Плюс, каждый раз с начала файла, а на 1.5G дампе (это ещё у меня не очень много вкладок было открыто) это не так быстро. wxHexEditor норм, умеет грузить только часть файла в память и довольно быстр. >потому что gcore часть регионов пропускал Пруф? >Отдает, но не всегда Пруф на строчку с вызовов сисколла brk в glibcшной реализации free или не отдаёт. // На самом деле я не помню наверняка, отдаёт ли он когда-нибудь или нет. >когда используется для отрисовки opengl А если не используется? Да и это чистая фантастика в любом случае, никогда ты не найдёшь там текстуру с нужным куском текста на экране, который был виден 10 минут назад. Ты бы ещё сказал из writebuf сетевухи вытащить, ололо.

@anonymous http://man7.org/linux/man-pages/man3/mallopt.3.html M_TRIM_THRESHOLD When the amount of contiguous free memory at the top of the heap grows sufficiently large, free(3) employs sbrk(2) to release this memory back to the system. (This can be useful in programs that continue to execute for a long period after freeing a significant amount of memory.) The M_TRIM_THRESHOLD parameter specifies the minimum size (in bytes) that this block of memory must reach before sbrk(2) is used to trim the heap. The default value for this parameter is 128*1024. Setting M_TRIM_THRESHOLD to -1 disables trimming completely. Modifying M_TRIM_THRESHOLD is a trade-off between increasing the number of system calls (when the parameter is set low) and wasting unused memory at the top of the heap (when the parameter is set high). Хм, мне казалось, что вообще не отдаёт. Впрочем, у Firefox вроде свой аллокатор.

@4da Во многих программах это не факт, что даст какой-то эффект, впрочем. >When the amount of contiguous free memory at the top of the heap Т.е. если мы аллоцировали 100 кусочков и осободили только 99 последних, то память системе так и не вернётся. https://stackoverflow.com/a/1421594

@anonymous да нет в браузере никаких аджакс-форм, мудила ты кружевной. как сделаешь так и будут работать. даже у артса ничего не проёбывалось из форм (хоть и сделано было конечно же через анус).

@anonymous Введи текст в форму, нажми отмена. Восстанови мне его.

@anonymous чо сказать-то хотел?

@anonymous нажми на карандашик

@mugiseyebrows В форму комментария.

@anonymous надо кнопку переименовать или убрать к хуям

@mugiseyebrows расстрелять!

@anonymous https://addons.mozilla.org/ru/firefox/addon/lazarus-form-recovery/

@anonymous Крутой совет, конечно, только как это поможет восстановить уже проёбанный комментарий?

@anonymous никак, потому что это не проблема, стоящая решения

@anonymous > Т.к. free(3) даже системе память не отдаёт Ты че ебанутый? Че ты здесь делаешь?

@anonymous > brk Точно ебанутый. Сколь-нибудь большие куски любая вменяемая libc выделяет через mmap.

@l29ah Читай выше, ебанатик.

@anonymous че

@l29ah Ебанатик, M_MMAP_THRESHOLD не просто так придуман. У mmap куча недостатков: On the other hand, there are some disadvantages to the use of mmap(2): deallo‐ cated space is not placed on the free list for reuse by later allocations; memory may be wasted because mmap(2) allocations must be page-aligned; and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). Во-вторых, посмотри как работает DEFAULT_MMAP_THRESHOLD_MAX (gilbc) и обосрись. С каждым free у тебя mmap будет использоваться всё реже и реже (до 32M на x86-64). В-третьих, большинство крупных приложений вроде firefox используют свой аллокатор и free не вызывают никогда.

@anonymous > memory may be wasted because mmap(2) allocations must be page-aligned; Че блядь, какой долбоёб это писал? У тебя защита памяти работает со страничной гранулярностью энивей. > and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). MAP_UNINITIALIZED > deallo‐ cated space is not placed on the free list for reuse by later allocations; Сорь не готов нырять в исходники ядра, но звучит бредово.

@l29ah Ты, походу, путаешься между тем, как память менеджится в ядре и внутри userspace в libc. >У тебя защита памяти работает со страничной гранулярностью энивей Если у тебя уже внутри процесса есть выделенные страницы памяти, то ты можешь любого размера куски из неё выделять. Что malloc и делает. >MAP_UNINITIALIZED Лол. Тебе объяснить куда пойти или сам догадаешься? Я уже не говорю о том, что оно по умолчанию выключено и включают только иногда в embedded. >Сорь не готов нырять в исходники ядра, но звучит бредово Речь про userspace код glibc. Если ты сделал free, то память ядру обычно не отдаётся, а помечается внутри процесса свободной и новая аллокация этого размера будет очень быстрой.

@anonymous > Если у тебя уже внутри процесса есть выделенные страницы памяти, то ты можешь любого размера куски из неё выделять. Что malloc и делает. И че? > Лол. Тебе объяснить куда пойти или сам догадаешься? Я уже не говорю о том, что оно по умолчанию выключено и включают только иногда в embedded. В таком случае brk должен тоже занулять страницы исходя из тех же соображений. > Речь про userspace код glibc. Если ты сделал free, то память ядру обычно не отдаётся, а помечается внутри процесса свободной и новая аллокация этого размера будет очень быстрой. И причём тут mmap?

@l29ah >В таком случае brk должен тоже занулять страницы исходя из тех же соображений. Зануляют не brk (при уменьшении data segment) или munmap, а при запрашивании новой страницы. Разница в том, что вызовы malloc/free для области с размером до M_MMAP_THRESHOLD не всегда приводят к brk, соответственно, остаётся какое-то количество памяти в запасе, которую можно выделять очень быстро, без сисколлов. Впрочем, такое же поведение (освобождаем память только после опрелённого threshold) можно было и для mmap сделать, а brk вообще не использовать. Вероятно, ещё какие-то причины есть. Может так быстрее, хз. mmap, я так понимаю, используется только для того, что можно для произвольной аллокации всегда память вернуть.

@anonymous Я говорил про выделение памяти brk в ответ на твою претензию к занулению при mmap же. Ну так все нормальные ЯВУ несут с собой консолидирующий gc, с которым проблема фрагментации огрызков не доставляет диких неудобств в виде утечки памяти и необходимости строгать свои особые аллокаторы // че там у хохлов?

@l29ah Так я тебе ответил, что malloc без участия mmap занулять будет реже, т.к. не всегда будет сисколл на выделение страницы. Немного по-тупому сформулировано, это особенность реализации в glibc такая просто: free для памяти, полученной с помощью mmap, всегда приведёт к munmap.

@anonymous > strings+grep хуита, кстати для моей задачи "получить урлы открытых в приватной сессии табов" было норм, там нет юникода. > Плюс, каждый раз с начала файла, а на 1.5G дампе Какой каждый раз? Один раз складываешь вывод strings в фаел, а потом пердолишь этот текстовик грепом. > Пруф? Какой в пизду пруф? Тебе не насрать, какие у меня тама трудности при решении моих проблем возникали? > Пруф на строчку с вызовов сисколла brk в glibcшной реализации free или не отдаёт. Сам головой подумай, нахуя тогда free, если он память не освобождает? Или ты никогда не видел, чтобы RSS у работающих приложений уменьшался? > А если не используется? Сейчас везде используется, по крайней мере, на десктопах. > Да и это чистая фантастика в любом случае, никогда ты не найдёшь там текстуру с нужным куском текста на экране, который был виден 10 минут назад. Люди из видеопамяти инфу даже после ребутов достают https://hsmr.cc/palinopsia/, все зависит от того, как организована работа с видеопамятью.

@4da В about:memory кнопки понажимая, увидишь как отдает (хотя и немного)

@anonymous > большинство крупных приложений вроде firefox используют свой аллокатор и free не вызывают никогда. У firefox используемый аллокатор от сборки зависит. В официальных, например, вроде, используется системный. И, да, free лиса вызывает.

@etw >Какой каждый раз? Вывод strings тоже может быть большим + не всегда оно подходит, как я уже писал. Даже строчки без юникода не всегда последовательно лежат, бывают разделители и куча мусора посередине. Я как-то вычищал пару раз такое. >Какой в пизду пруф? Мне интересно, тоже пригодится. Если уж упомянул, то поясни, хуле. >Сам головой подумай, нахуя тогда free, если он память не освобождает? Ты ебанько и слоупок, выше уже всё обсудили с пруфами. Твои девчачьи аргументы "а зачем тогда сделали" здесь никого не интересуют. >Сейчас везде используется >Люди из видеопамяти инфу даже после ребутов достают Только последний кадр так можно сдампить, выше писал. Но атака, особенно про виртуалбокс, интересная, спасибо.

@etw Кэп. А если не нажимать?

@etw >И, да, free лиса вызывает. Пруф? (Кроме кнопок в about:memory.)

@anonymous Тогда GC вызовется хуй знает когда, но ты этого, скорее всего, не заметишь.

@etw Да, это возможно. Тогда всё-таки есть шанс, хоть и небольшой, что память утечёт обратно к ядру. Притом что надо ещё успеть сдампить /dev/mem, пока другое приложению ту же страницу не выделили, т.к. ядро занулит тогда. Но на практике об этом можно не париться, там гораздо опаснее, что firefox в пределах своего процесса эту память перезатрёт.

@anonymous > Вывод strings тоже может быть большим + не всегда оно подходит, как я уже писал. Для конкретного случая strings core.1234 | grep -F "http" значительно сократит объем, алсо, когда я той проблемой занималась, сырой вывод strings был не таким уж и большим, чтобы с ним было сложно работать (сам дамп был размером примерно в 4 гигабайта) > Даже строчки без юникода не всегда последовательно лежат, бывают разделители и куча мусора посередине. в лисе адреса табов из strings вылезают в виде подобном ["https://bnw.im/"] иногда с небольшим количеством мусора перед или после. > Мне интересно, тоже пригодится. Если уж упомянул, то поясни, хуле. сейчас Gcore на текущем процессе с RSS 2G выдает пачку ошибок вида ```warning: Memory read failed for corefile section, 327680 bytes at 0x3cf4f000.``` и результирующий дамп, если выкинуть пустые области занимает сотни килобайт. > Ты ебанько и слоупок, выше уже всё обсудили с пруфами. Если ты, кретин, ни разу в жизни не видел, как RSS у процесса уменьшается, то это не мои проблемы. > Твои девчачьи аргументы мои > Только последний кадр так можно сдампить, выше писал. Но атака, особенно про виртуалбокс, интересная, спасибо. Как я уже сказала, это зависит от того, как организована работа с VRAM. Если у тебя от отдельному буферу на каждое окно, то о содержимое закрытых окон может оставаться в памяти нетронутым часами. Никогда не видел что ли, когда иксы тупят при от/перерисовке какого-либо окна и у тебя там оказываются куски текстур старых окон, которые ты уже давно закрыл?

@anonymous Кнопки в about:memory просто явным образом дергают гц, который и без них регулярно запускается. А, вообще, сделай strace и посмотри сам, чо ты как маленький.

@etw >Gcore на текущем процессе с RSS 2G выдает пачку ошибок вида Интересно, почему? Что там по этим адресам? Надо тоже затестить. У меня gcore вроде нормально работал. >Если ты, кретин, ни разу в жизни не видел, как RSS у процесса уменьшается, то это не мои проблемы. Сделай миллион маллоков по 127 килобайт, сделай фри на всё, кроме последнего. Тогда посмотрим кто после этого кретин. >Как я уже сказала, это зависит от того, как организована работа с VRAM. Да как угодно. Если у тебя был в табе в одном из полей текст и ты его затёр, а после этого ещё и проскроллил страницу, то хуй ты его обратно из видеопамяти достанешь, не будет там уже такой текстуры. Хватит уже защищать, как баран, идиотский аргумент. >который и без них регулярно запускается Т.к. бывает, что освобождает прилично, то, скорее всего, достаточно редко. Сам смотри и сюда потом с пруфами. А то сейчас пойдёшь доказывать существование бога, ЕВПОЧЯ.

@anonymous > Интересно, почему? Что там по этим адресам? Что-что, хипы тама. > Сделай миллион маллоков по 127 килобайт, сделай фри на всё, кроме последнего. Сделала http://pastebin.com/Z2L7Q9Na // Сначала раздувается до 127+ МБ, после энфорса trim-а сдувается до 200+ КБ > Да как угодно. Если у тебя был в табе в одном из полей текст и ты его затёр, а после этого ещё и проскроллил страницу Еще раз для тупых, результат сильно зависит от того, как менеджатся буферы отрисовки браузером (если речь идет про саму страницу), тулкитами (если они рендерят виджеты, а обычно они это делают) и иксами. > Т.к. бывает, что освобождает прилично, то, скорее всего, достаточно редко. Нет, просто у лисы хуевый гц, который даже явно вызваный обычно нихуя не освобождает. > Сам смотри и сюда потом с пруфами. Открыла strace, нажала кнопку в about:memory, увидела пачку munmap-ов. Теперь ты доволен? Если нет, то вот тебе кусок лога (текстового, лол) в качестве пруфа ``` [pid 19009] munmap(0x7f3511f08000, 65536) = 0 [pid 19009] munmap(0x7f3510d9c000, 65536) = 0 [pid 19009] munmap(0x7f351097a000, 65536) = 0 [pid 19009] munmap(0x7f350cbe0000, 65536) = 0 [pid 19009] munmap(0x7f350f776000, 65536) = 0 [pid 19009] munmap(0x7f35105a4000, 77936) = 0 ```

@etw >Сделала http://pastebin.com/Z2L7Q9Na А теперь сделай ещё memset после malloc, запускай с strace, в отдельном шелле запусти `watch -n0.1 ps -C a.out -o cmd=,rss=,vsz=` и подумай немного над этими строчками из man madvise: After a successful MADV_DONTNEED operation, the semantics of memory access in the specified region are changed: subsequent accesses of pages in the range will succeed, but will result in either repopulating the memory contents from the up-to-date contents of the underlying mapped file (for shared file map‐ pings, shared anonymous mappings, and shmem-based techniques such as System V shared memory segments) or zero-fill-on-demand pages for anonymous private mappings. Note that, when applied to shared mappings, MADV_DONTNEED might not lead to immediate freeing of the pages in the range. The kernel is free to delay freeing the pages until an appropriate moment. The resident set size (RSS) of the calling process will be immediately reduced however. Внезапно так, да. И посмотри какой там адресок у brk после nanosleep. Большой, верно? Т.е. сегмент данных у программы как был >128 мегабайт, так и остался, просто мы попросили ядру показывать нам в RSS *как будто* мы его освободили. Ты вообще пытался свой пример проанализировать? Я уже не говорю о том, что malloc_trim тебя никто не просил вызывать. >результат сильно зависит от того, как менеджатся буферы отрисовки браузером Не юли, не будет там такой текстуры. Или, по-твоему, на каждое поле ввода тулкит свою текстуру создаёт? И хранит в промежуточные результаты в течении десятка минут? Нет, я не верю, что можно на полном серьёзе такую хуйню нести. >Открыла strace, нажала кнопку в about:memory А если не нажимать? Вопрос был про то, как часто он это делает самостоятельно. Причём именно firefox для данных со страниц, а не либы, которые он использует.

@anonymous > Т.е. сегмент данных у программы как был >128 мегабайт Кого ебет размер сегментов в виртуальной памяти? > просто мы попросили ядру показывать нам в RSS как будто мы его освободили Мы и освободили соответствующие тем участкам страницы физической памяти. А какие тама приколюхи ведро устраивает с виртуальной - ебет слабо. > Я уже не говорю о том, что malloc_trim тебя никто не просил вызывать Тест синтетический же. Реальные приложения, если не ебутся со своими memory pool-ами, выделяют и освобождают разные куски памяти постоянно и проще воткнуть trim, сымитировав то, что аллокатор решил потримить память, чем делать синтетику ближе к поведению реального софта. > Или, по-твоему, на каждое поле ввода тулкит свою текстуру создаёт? Окай, для совсем тупых (для тебя) объясню еще раз: я не знаю, что тама делает лиса (не тулкиты, разумеется) с рендерингом фрейма для коммента на мяу и лезть в ее говнокод мне не хочется, потому я говорю, что останется текстура в видеопамяти или нет - сильно зависит от реализации движка рендеринга лисы (а также от того, как сделана страница). Рендеринг может быть реализован послойно и коммент будет находится на отдельном слое, тогда текстура, возможно, останется. Если ты уверен (лично я - не уверена), что не останется - предъяви пруфы. > А если не нажимать? Вопрос был про то, как часто он это делает самостоятельно. Причём именно firefox для данных со страниц Сорьки, strace не делится со мной (да и не должен), из каких функций выли вызваны munmap-ы. Могу только добавить, что при закрытии вкладок тоже прилетают большие пачки munmap-ов для соседних регионов.

@etw >Тест синтетический же. И что он показал? Вполне такое может быть, что мы много мелких кусков застобили другим долгоживущим куском и никакой памяти не освобождается на free, даже после M_TRIM_THRESHOLD (он malloc_trim не вызывает, просто sbrk). malloc_trim обычно никто не использует, т.к. тормоза. Для этого, собственно, аллокация с помощью mmap и придумана, чтобы всегда можно было вернуть память ядру. >Мы и освободили соответствующие тем участкам страницы физической памяти А вот давай ты мне вначале расскажешь, кукаретик, что делает madvise DONTNEED в случае памяти, которую не выделяли через mmap, т.к. в мане это всё слишком мутно и только про mmap? trim здесь вызывать вообще не надо было, т.к. его вызов brk ничего и не освобождает практически. Ты нашёл сисколл, который позволяет в дата сегменте процесса сделает дырку, пометив память как типо ненужную и после этого утверждаешь, что это то, о чём я просил? А своей тупой головой не мог подумать, почему я попросил аллоцировать именно 127, а не 129 килобайт? Чтобы ты потом вызвал DONTNEED и типо показал, что free освобождает память для аллокаций этого размера? Иди на хуй с таким уровнем дискуссии, плиз. >Если ты уверен (лично я - не уверена), что не останется - предъяви пруфы. Охуеть. А кто в #XLQYIQ/U8X это первый придумал? Давай ты опять пойдёшь нахуй^W^W доказывать мне существование бога с такими аргументами? Твои догадки, основанные ни на чём, кроме желания, как баран, упираться в тупой аргумент и остаться правым, здесь никого не ебут. С этим к личному психологу, пожалуйста.

@anonymous >даже после M_TRIM_THRESHOLD (он malloc_trim не вызывает, просто sbrk) Немного не так сказал. Вроде как free как раз malloc_trim и вызывает, но только после того, как sbrk может освободить достаточно памяти, не раньше. Вопрос про DONTNEED, впрочем, в силе: нахуя это, как это согласуется с остальной логикой brk и как оно работает для не-mmap.

@anonymous Кстати, /proc/pid/maps до вызова malloc_trim и после показывает ровно единтичную картину, за исключением чуть-чуть сократившегося heap на одну страницу после вызова brk (подозреваю, некоторый избыток malloc, который trim фиксит). Никакой дырки внутри heap не наблюдается. Что-то мне подсказывает, что здесь есть наёб и ничего на самом деле не освобождается.

@anonymous Я тут ещё подумал. Теоретически, это могло бы действительно возвращать страницы памяти сегмента heap обратно ядру, делая картину аналогичной вызовам malloc без memset (т.е. COW, виртуально аллоцировано, но страницы физические не смапплены, а при чтении будут нули). Но вот нахуя тогда brk используют, имея этот механизм - не ясно.

@anonymous > И что он показал? Хуй знает, что ты своим тестом хотел показать. По мне, так тест говно. > мы много мелких кусков застобили другим долгоживущим куском Поясни, не распарсила. Ты имеешь в виду, что мы выделили memory pool? > А вот давай ты мне вначале расскажешь, кукаретик, что делает madvise DONTNEED Помечает страницы виртуальной памяти как неиспользуемые, чтобы, в случае, если память приватная, ядро могло освободить соответствующие им физические страницы, а потом, если ты решишь обратиться к ним, выделить тебе память по pagefault-у. > Охуеть. А кто в #XLQYIQ/U8X это первый придумал? Назвала вариант как возможный, который может сработать, если повезет. > Твои догадки, основанные ни на чём, кроме желания, как баран, упираться в тупой аргумент и остаться правым, здесь никого не ебут. Я тебе уже в третьем комменте объясняю, что вариант с текстурой зависит от реализации рендереров и, ВОЗМОЖНО, сработает (если при этом память еще не перезатрется), на что ты поливаешь меня говном и заявляешь с уверенностью, что текстуру 146% нельзя вытащить. Пруфы давай или нахуй иди, короче.

@anonymous > Никакой дырки внутри heap не наблюдается. Отсутствие дырки в представлении виртуальной памяти не означает, что хоть какие-то страницы физической памяти с этим участком связаны.

@etw >Поясни, не распарсила. Может так случиться, что последний выделенный кусок памяти по какой-то причине долго не освобождается. В результате память под куски, выделенные до этого, нельзя вернуть системе. >Помечает страницы виртуальной памяти как неиспользуемые Гадать я и сам умею (см. #XLQYIQ/YDL), ты лучше вот что скажи: 1) Тебя не смущает, что в мане ни слова про обычные сегменты памяти 2) А также приписка по поводу того, что ядро может на очистку и забить? То, что у тебя RSS показывает, ещё ни о чём не говорит. 3) Ок, пусть оно работает так. Зачем нам тогда brk для возврата памяти? Мы ведь можем всегда очищать через DONTNEED по аналогии с munmap, не парясь о том, где вообще лежит память, которую мы освобождаем.

@anonymous Зачем тебе лишнее говно в таблице меппинга в прыщах? Слишком быстро пейджфолты обрабатываются тип?

@l29ah В чём разница по сравнению с операцией уменьшить и увеличить дата-сегмент с помощью brk? То, что память виртуальная идёт последовательно, совсем не означает, что маппится она также последовательно в физической. И там будут такие же пейджфолты при первоначальном обращении.

@anonymous че Ты спросил зачем брать и не отдавать. Я объяснил.

@anonymous > Может так случиться, что последний выделенный кусок памяти по какой-то причине долго не освобождается. В результате память под куски, выделенные до этого, нельзя вернуть системе. Последний кусок в странице памяти? Ну и похуй. А так-то память у нас виртуальная, осталась дырка - не беда, система отмапит физические страницы под новое выделение в другом месте виртуальной памяти, у нас ее 16 ЭБ. > Тебя не смущает, что в мане ни слова про обычные сегменты памяти Мadvise работает не отображениями, а со страницами памяти, анонимный mmap - просто один из способов их выделить. На поведение DONTNEED влияет то, являются ли страницы памяти приватными или же общими. > Ок, пусть оно работает так. Зачем нам тогда brk для возврата памяти? Затем, что адресное пространство все-таки конечное и, например, на 32-битных системах его всего 4 ГБ, а делать отдельную логику для 64 смысла нет.

@anonymous Палю mallopt(3) > Allocating memory using mmap(2) has the significant advantage that the allocated memory blocks can always be independently released back to the system. (By contrast, the heap can be trimmed only if memory is freed at the top end.) On the other hand, there are some disadvantages to the use of mmap(2): deallocated space is not placed on the free list for reuse by later allocations; memory may be wasted because mmap(2) allocations must be page-aligned; and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). Balancing these factors leads to a default setting of 128*1024 for the M_MMAP_THRESHOLD parameter.

@l29ah Так brk и отдаёт. Можно было всю логику освобождения памяти сделать через DONTNEED, не парясь насчёт её расположения.

@etw Ты ебёшься в глаза, я эту цитату уже сам здесь постил.

@etw >у нас ее 16 ЭБ 2^48 вообще-то. Кое-кто здесь не сечёт в трансляции виртуальной памяти, а уже спорить лезет. >осталась дырка - не беда Так никто trim вручную и не вызывает. А когда он сам вызовется - это уже большой вопрос. >Мadvise работает не отображениями, а со страницами памяти Это только твои домыслы. >Затем, что адресное пространство все-таки конечное А тремя строчками выше расписывал как её дохуя. Не принимается. В чём разница между уменьшить и увеличить heap, и сделать дырку, а затем сразу использовать временно освобождённые страницы? inb4 лишние записи в таблице трансляции

@etw Тебя, кстати, не смущают слова "By contrast, the heap can be trimmed only if memory is freed at the top end" в твоей собственной цитате? Или ты принципиально не вчитываешься и не вдумываешься в то, что делаешь? Никто про дырки не упоминает почему-то. В мане про malloc_trim тоже ни слова. Как ты это собираешься объяснить?

@anonymous Олсо, почитал немного тута https://github.com/torvalds/linux/blob/5879ae5fd052a63d5ac0684320cb7df3e83da7de/mm/madvise.c#L257-L275 и тута http://www.slideshare.net/yandex/linux-44775898 и оказывается, что anonymous private mapping это в том числе и область heap, полученная с помощью brk (= mmap(anon, private)). И DONTNEED в Linux действительно сбрасывает маппинги на физические страницы. Но ты всё равно сосёшь :3 Тебя этот madvise вызывать никто не просил. То, что он есть - круто, вот только вызов free(3) не всегда приводит к вызовам malloc_trim(3).

@anonymous Кстати, обрати ещё внимание на коммент к madvise. Там прямо говорится, что освобождение страниц происходит не сразу. Если сделать DONTNEED, а потом сразу же прочитать обратно, то мы, вероятно, получим назад наши данные.

@anonymous Ты тупой сука, перечитай блять мой камент.

@l29ah Нет ты. Ты привел пример, когда мы с помощью brk heap уменьшили, уменьшив и число трансляций. Но ты так и не объяснил две вещи: 1) Когда мы снова захотели выделить память, разницы между brk и обращением в ту самую дырку не будет. С brk даже дольше будет, т.к. там сисколл + page fault + COW, а с дырой только page fault + COW. 2) Даже если больше до конца жизни программы нам больше не нужна память (тупой юзкейс на самом деле), то мы и в эти страницы тыркаться не будем и никаких page fault не будет. Тебе мешают эти записи в таблице трансляций или что?

@anonymous Где я что-то говорил про brk? Мешают. Как выглядит таблица трансляций по-твоему?

@l29ah >Где я что-то говорил про brk? Ну тогда это ты тупой, т.к. вообще не понимаешь о чём идёт речь. Всё уже было расписано тысячу раз. >Мешают. Как выглядит таблица трансляций по-твоему? Небольшая структурка с опциональными указателями на физические страницы. http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/ Немного не пойму, что тебе даст небольшой уменьше конечного адреса сегмента heap у процесса. Хуле ты тут мнёшься как тёлка? Если есть что сказать, то говори.

@anonymous Судя по тем вопросам, которые ты задаешь, либо ты не понял ее смысл, либо сам ебешься в глаза. Там, вроде, понятно написано, почему применяется brk и почему mmap.

@etw Да? Тебе правда понятно? См. #XLQYIQ/4W7, умник.

@anonymous Какие дырки, ты что несешь? трим освобождает те страницы, которые относятся к непрерывному куску памяти в конце data сегмента, для которой сделали free(3).

@etw А это что → https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=452f036387e0b5699e8f0fa33ed027abf066115e;hb=HEAD#l4528 ? Кто соснул?

@anonymous Кстати, да, я тут понял, что @etw соснул **ЕЩЁ РАЗ**. Если вызывать free, то вызывается systrim. А madvise вызывается только при ручном malloc_trim. Так что все твои аргументы типа "фаерфокс просто делает фри и всегда уменьшается RSS" автоматически идут лесом :3

@anonymous > 2^48 вообще-то Сорь, я тупой админ прост. > А когда он сам вызовется - это уже большой вопрос. Когда-нибудь да вызовется. Если тебя сильно волнует когда именно, глянь в исходники glibc. > Это только твои домыслы. В mm/madvise.c адреса в аргументах сискола транслируются в vma структуры. Да и, вообще, brk вызов в mm/mmap.c является немного упрощенным вариантом mmap-а. > А тремя строчками выше расписывал как её дохуя. Тремя строчками выше я писала с точки зрения прикладного программиста под amd64, когда он выбирает как ему писать код и может позволить себе делать неэффективные аллокации (либо дебил прост, если не экономит виртуальную память, когда ее мало, но это, опять же, его личные проблемы), а тут - про точку зрения разработчика glibc, который из-за разнообразия платформ, на которых его код может работать, не может себе разбрасыватся виртуальной памятью никогда.

@anonymous > Но ты всё равно сосёшь :3 То чувство, когда тупая шлюха-админ разбирается в работе с памятью в прыщах лучше тебя :3 > вот только вызов free(3) не всегда приводит к вызовам malloc_trim(3) и че, что не всегда?

@etw >точку зрения разработчика glibc, который из-за разнообразия платформ, на которых его код может работать, не может себе разбрасыватся виртуальной памятью никогда Ну это уже возможно. Получается всё как-то переусложнено просто - три варианта менеджмента памяти: brk (для увеличения и уменьшения), mmap (для увеличения и уменьшения) и madvise (для уменьшения).

@anonymous > Кстати, обрати ещё внимание на коммент к madvise Зачем обращать? О чем это поведение говорит? > то мы, вероятно, получим назад наши данные Или не получим. Закладываться на undefined behaviour - себе дороже, а для задач, требующих трансциндентную память есть legit механизмы.

@etw >То чувство, когда тупая шлюха-админ разбирается в работе с памятью в прыщах лучше тебя :3 Зато теперь я лучше в этом разобрался :3 >и че, что не всегда? Точнее к вызову madvise он никогда не приводит, см. выше. А systrim в случае того синтетического теста, который мы рассматривали, ничего не освободит.

@anonymous Пиздец ты тупой. Прочитай #XLQYIQ/88B еще раз: выбор brk/mmap сделан преимущественно из-за эконопии виртуального адресного пространства (потому что есть платформы, где его мало), чтобы при worst case сценарии было меньше дырок в выделенных регионах.

@anonymous Документация > The malloc_trim() function attempts to release free memory at the top of the heap (by calling sbrk(2) with a suitable argument).

@etw Вопрос был в том зачем вообще brk, если можно всё на mmap. munmap всегда память возвращает и еботни с madvise не надо.

@etw Документация > код ? Пожалуй, это слишком тупо даже для админа.

@anonymous > Если вызывать free, то вызывается systrim. А madvise вызывается только при ручном malloc_trim. и че, физическая память теперь из-за этого не освобождается что ли? > "фаерфокс просто делает фри и всегда уменьшается RSS" Где у меня было про "всегда"? Напомню, что это ты пиздел в #XLQYIQ/Q3X, что free никогда память не возвращает, а я говорила, что возвращает при определенных условиях.

@etw >и че, физическая память теперь из-за этого не освобождается что ли? 1) Только после определённого threshold (M_TRIM_THRESHOLD). 2) В некоторых случаях (долгоживущая последняя аллокация) - вообще нет. >что free никогда память не возвращает Да, здесь я напиздел. Но на практике оно и не так часто возвращает, как ты тут расписывал.

@anonymous > Точнее к вызову madvise он никогда не приводит, см. выше. А systrim в случае того синтетического теста, который мы рассматривали, ничего не освободит. ну и? Я не понимаю, ты считал, что у сложного chunk-based аллокатора можно легко вслепую предугодать поведение, тип он однозначно освобождает память или нет? Ну да, нельзя, потому я и говорила, что твой синтетический тест - говно. Пиздец, я с тебя хуею.

@etw >Ну да, нельзя, потому я и говорила, что твой синтетический тест - говно А хуйли тогда надо было 50 комментов подряд нудеть по поводу malloc_trim и madvise? Так бы и сказал сразу, фигли. А то зафигачил malloc_trim и показывает мне как RSS волшебным образом уменьшается, охуеть теперь.

@anonymous Как раз для админа норм. Ебанешься листать на каждый чих сорцы всего, что приходится админить.

@4da Оперативно.

@etw Ты такая милая, когда оправдываешься :3

@4da У нее тама библиотека для отрисовки используется: раньше был cairo, теперь azure. Что внутри тама под прыщами не знаю, но под виндой, вродь, используется D3D.

@anonymous Для тебя в цитате #XLQYIQ/88B написано, почему разработчики glibc оставили brk. Пиздец, ты совсем тупой что ли?

@etw -_\\ Перечитай ещё раз #XLQYIQ/4W7 Или просто скажи, что ты девушка, админ и вообще не понимаешь в этих ваших линуксах.

@anonymous > Но на практике оно и не так часто возвращает, как ты тут расписывал. Где я расписывала, как часто? Могу вспомнить только > Отдает, но не всегда, только если, грубо говоря, если опустить приколюхи с чанками, на странице больше не осталось занятых процессом участков.

@anonymous Сорь, ты прав, надо было сразу в википедию тебя отправить, а не делать допущение, будто ты знаешь, что в глибц аллокатор не совсем тупой.

@etw Только ты забыл упомянуть, что это относится к концу сегмента только.

@anonymous > Перечитай ещё раз #XLQYIQ/4W7 Читаю и вижу, что ты говоришь про выделение и освобождение физической памяти (может, я тупая прост?), а выбор mmap/brk авторами glibc был сделан для экономии виртуальной.

@etw Ну ок. Напишу ещё раз. Минусы mmap со слов man mallopt: >deallocated space is not placed on the free list for reuse by later allocations Можно также не делать сразу munmap, а хранить некоторое количество для дальнейшего использования. >memory may be wasted because mmap(2) allocations must be page-aligned brk тоже page aligned. >and the kernel must perform the expensive task of zeroing out memory Если мы увеличили сегмент heap с помощью brk, то на всех новых страницах **тоже** будет page fault с занулением. В общем, или я тупой, или mmap ничем не хуже. Разница только в деталях реализации glibc.

@anonymous Я бы не стала говорить за data сегмент, потому что не знаю, к каким сисколлам в итоге приводит вызов malloc лисой. Там может оказаться mmap, а не brk.

@anonymous > Можно также не делать сразу munmap, а хранить некоторое количество для дальнейшего использования. Т.е. писать дополнительный код для управления кусками отображений и переделывать уже работающий аллокатор, либо получится "йо псы, давайте сделаем чанки внутри чанков, чтобы выделять память, когда мы выделяем память". > brk тоже page aligned. Разумеется, page aligned. Но аргументы не обязытельно должны быть такими, т.е. эта работа перекладывается на ядро. А в случае с mmap это должна делать glibc. Подозреваю, что разработчики просто не хотят писать дополнительный код для случая выделения небольших кусков памяти. > Если мы увеличили сегмент heap с помощью brk, то на всех новых страницах тоже будет page fault с занулением. Да, но это будет в момент выделения памяти, а не в момент обращения к ней, что может оказаться важным для некоторых задач. Почему не использовали для небольших аллокаций mmap с POPULATE - не знаю. Подозреваю, что изначально для совместимости с разным ядрами и портируемости, а также потому, что кода меньше вряд ли станет. А теперь так сделано просто потому что уже сделано.

@etw >Т.е. писать дополнительный код для управления кусками mmap можно передать адрес, значит их можно расположить прям последовательно в виртуальной памяти, как heap. >Подозреваю, что разработчики просто не хотят писать дополнительный код для случая выделения небольших кусков памяти. Чёт не понял, ну да ладно. >Да, но это будет в момент выделения памяти, а не в момент обращения к ней Ты уверен? Из того, что я читал, увеличение сегмента данных с помощью brk такое же ленивое. Вот здесь хотя бы: http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/

@anonymous > mmap можно передать адрес, значит их можно расположить прям последовательно в виртуальной памяти, как heap. Первый аргумент у mmap - это совет ядру, где расположить отображение, которому оно не обязано следовать. Это не то, чем можно управлять из юзерспейса и, соответственно, аллокатор на этом не построить. > Чёт не понял, ну да ладно. Надо выравнивать length по границе страницы, а для brk - нет. Хотя, конечно, так себе причина. Возможно еще это сделано для локальности данных и ускорения доступа к ним, но я не уверена. > Ты уверен? Из того, что я читал, увеличение сегмента данных с помощью brk такое же ленивое. Да, таки ленивое (если страница не заблокирована от вытеснения).

@etw >Это не то, чем можно управлять из юзерспейса и, соответственно, аллокатор на этом не построить. >on Linux, the mapping will be created at a nearby page boundary. же. Вполне всё детерминистично. У меня из предположений только: скорость + лучшая совместимость (где mmap нет, по крайней мере механизм brk будет работать). Но это так, спекуляции.

@anonymous > же. Вполне всё детерминистично. А если в желаемом регионе уже выделена память (например, пользователем через ручной mmap)?

@etw MAP_FIXED ёпт.

@etw А если пользователь сделает mmap на текущий program break, malloc маленьких чанков перестанет работать? (Мне в самом деле интересно.)

@l29ah И поиметь проблемы с переносимостью и написать дополнительный код для проверки таких ситуаций. А ради чего? Чтобы просто все делать через mmap потому что "почему бы нет"?

@etw Не ебу нахуя вы в эту сторону трындите. Если речь про прыщи, то никаких проблем с переносимостью не будет. Разве что тебе нужно не попасть по ядру.

@l29ah Но вообще это сведёт на нет aslr, что печально.

@etw Более простой код и всегда есть возможность вернуть память ядру. В том числе и меньше виртуальной памяти будет расходоваться, т.к. madvise виртуальную память не уменьшает. (Хотя про виртуальную память это так себе аргумент.)

@l29ah Не сведёт. Начало так и останется рандомным, а дальше последовательный рост. Также как и heap.

@anonymous не знаю, посмотри исходники

@l29ah Славик пытается понять, почему разработчики глибц сделали именно так, как есть. А глибц как бы не только под прыщами работает.

@anonymous > Более простой код Все равно, по идее, останется разделение логики на выделение больших кусков памяти и маленьких > есть возможность вернуть память ядру аллоцированную через brk память тоже можно вернуть ядру через еще один вызов brk. и виртуальная тоже освободится.

@etw Не всегда ж. Потому mmap и используется для больших кусков.

@anonymous Если считать, что в случае множества небольших аллокаций память будет освобождаться в конце тех функций, где была выделена, но, по идее, все будет хорошо.