Как получить размер максимального объема памяти, которую может занять процесс?

Какое отношение к порядку следования байт, скажем, в long int, имеет __WORDSIZE?

А ты не говнокодер?

пытаюсь им не быть.

И как же ты определяешь архитектуру, на которой компиляется код?

никак. ИМХО код должен одинаково хорошо работать на _любой_ архитектуре.

ИМХО код должен одинаково хорошо работать на _любой_ архитектуре.

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

У него всё на чарах - у него нет этой проблемы, он сам пишет софтварно порядок байт, чтобы оно «хорошо работало на _любой_ архитектуре».

Молодец, ты хорошо затралил. Какраз в тему о чарах.

Ну, это не всегда удобно. Если у тебя, скажем, параллельная 64-битная шина, то как-то не вариант по ней чары гонять.

А вообще, конечно, можно найти выход, а также можно придумать ситуацию, когда этот выход не сработает или будет сильно тупить. Скажем, в том же STM32 я как раз чарами и стал передавать. И от DMA отказался. Но там еще один косяк есть: длина посылки по SPI — от 1 до 4 байт, DMA бы тут никак не прокатило.

ИМХО код должен одинаково хорошо работать на _любой_ архитектуре.

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

мы начали не про порядок, а про размер указателей. Теперь объясни, зачем мне, как программисту, знать, какой размер у моих указателей?

Велосипеды нужны только если обосновать это твоё НУЖНО. А его обоснованность под сомнением. Даже если тебе нужно сохранить разность указателей, то для тебя есть ptrdiff_t. Если тебе нужен тип данных, в который влезет любое количество объектов, на которые можно указать, то у тебя есть size_t. Теперь расскажи, зачем тебе понадобился этот размер?

Ну, это не всегда удобно. Если у тебя, скажем, параллельная 64-битная шина, то как-то не вариант по ней чары гонять.

что мешает гонять данные memcpy(3)? Она лучше знает, какая там шина.

Я влез как раз по поводу порядка следования байтов. Мне пофиг, какой там размер у указателей.

А если тебе нужен низкоуровневый доступ? И, кстати, еще вариант: у тебя нет memcpy, у тебя нет glibc.

В линуксе никогда не возникает такого исключения.

Позавчера своими глазами видел.

А если тебе нужен низкоуровневый доступ?

тогда портабельность и мультиархитектурность накрываются ЖПП. Тебе надо писать два варианта, по любому.

И, кстати, еще вариант: у тебя нет memcpy, у тебя нет glibc.

значит нужно писать свой аналог memcpy(3) для данной железяки.

Который не работает. ты бэдаллок зачем-то привел, только вот он не работает - зачем ты про него говорил? Форфан? И да - ты ответил на онтопик, а онтопик - память, ты говорил о памяти априори.

Там говорилось об этом:

В линуксе никогда не возникает такого исключения.

Я же скомпилял и проверил — такое исключение возникает. Вот и все.

Скажем так... встречается :)

Короче, господа знатоки, то, что мне нужно было - это RLIMIT_DATA, про который говорил arturpub, спасибо ему за это. Можно расходиться и дальше не сраться в этой ветке.

Там еще RLIMIT_AS есть, он mmap'ы учитывает. Слышал некоторые системы отправляют большие malloc'и в mmap, так что вот.

Ололо, ты пониамешь, что это вообще такое? Это общие лимиты, которые больше чем вся память, которую ты видел в своей жизни вместевзятая.

Это максимальная память, которую ты можешь заммапить - ты её итак знаешь - это в районе 3с хвостом гигов.

Я уже тебе рассказал - как детектить память:

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <stdint.h>

#define bind(f, arg) ({typeof(f(arg)) new(void) { return f(arg);} new;})

void * alloc_page(uint64_t flags) {
  return mmap(NULL, 4096, PROT_WRITE | PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS | flags, 0, 0);
}

#define PINMB ((1024ul*1024)/4096)
#define MYMEM ((1024ul*1024*1024)*16)

typedef void*(*allocf_t)(void);

int overmax(void) {return !fprintf(stderr, "OVERMAX\n");}

uint64_t find_max(allocf_t f) {
  uint64_t i = 0, max = MYMEM/4096;
  while(({int t = (f() != -1ul); i += t; t;}) && ((i < max) || overmax()));
  return i;
}

int main(void) {
  fprintf(stderr, "%luMB\n", find_max(bind(alloc_page, 0))/PINMB);
  fprintf(stderr, "%luMB\n", find_max(bind(alloc_page, MAP_POPULATE))/PINMB);//это захватывает память и она 100% твоя, возвращает -1ul, когда памяти уже нет, 100% нет.
  fprintf(stderr, "%luMB\n", find_max(bind(alloc_page, MAP_POPULATE))/PINMB);
  fprintf(stderr, "%luMB\n", find_max(bind(malloc, 4096))/PINMB);
}

На либц ты не можешь этого определить, возможно на 32битных фекалих это будет работать, если твоя программа монополист, но реально это редко бывает и приучаясь ваять бесполезные кастыли - ты ваяешь бесполезные кастыли и дальше.

Измени в find_max() страницу на метров10-20, а mmap() на mremap() - ты получишь 100% рабочий захват максимального кол-ва памяти в любом случаее. Ты можешь потом её отмапить, но никто тебе не гарантирует, что её останется столько же.

Это не имеет смысла, лимит - это системная штука, которая конкретно к твоей программулинке мало относится.

То, что ты показал - это общие лимиты для brk(), либо для mmap()+brk() - верхние пределы адресов, причем это виртуальная память. Эти лимиты будут одинаковыми и для 30гигов памяти и для 128метров - т.е. они бесполезны.

Слышал некоторые системы отправляют большие malloc'и в mmap, так что вот.

Это без разницы. Брк - это стек, второй стек, который растёт вверх по адресам ~0-> и если на пути ему попался mmap(), который ммапит обычно в другую сторону - т.е. <-~max - будет фейл. Вызвав mmap() - ты уже примерно можешь получить лимит, после которого маллок() зафейлится.

Но как я уже говорил ранее - это всё не имеет смысла. Это может считать ведро с прямой адресацией и реальными лимитами, но для юзерспейса это недоступно. И эту лимиты уже лет 100 как протухли, нужны только для постановки ограничений, чтобы допустим процессы на твоём хосте не жрали больше Nпамяти.

Вызвав mmap() - ты уже примерно можешь получить лимит, после которого маллок() зафейлится

Если бы ты внимательно читал, ты бы уловил мысль о том, что некоторые системы при malloc(n), где n больше некоторого порогового значения, используют не brk-область, а mmap'ят этот большой регион, дабы не трешить кучу. И malloc волен при достижении границы brk vs mmap дальше использовать исключительно mmap для выделений. Какой параметр может это ограничить, кроме RLIMIT_AS, ты нам конечно же не расскажешь.

нужны только для постановки ограничений, чтобы допустим процессы на твоём хосте не жрали больше Nпамяти

Не разумно ли использовать этот же механизм для приемки этих ограничений?

Феерический g-code.

Если бы ты внимательно читал, ты бы уловил мысль о том, что некоторые системы при malloc(n), где n больше некоторого порогового значения, используют не brk-область, а mmap'ят этот большой регион, дабы не трешить кучу.

Не рассказывай мне пж про маллок и как он работает. Маллок никак не относится к системе - во всех вменяемых libc он работает именно так.

Какой параметр может это ограничить, кроме RLIMIT_AS, ты нам конечно же не расскажешь.

Зачем это ограничивать, причем сдесь онтопик? Этот лимит никак не гворит «Как получить размер максимального объема памяти, которую может занять процесс?», а то, что ты уже приплёл сюда нужность каких-то ограничений - твоя лужа.

Я тебе уже описал стратегию работы brk() и mmap() - другой стратегии быть неможет по определинию, поэтому ты вообще думаешь, когда несёшь такую хрень:

при достижении границы brk vs mmap дальше использовать исключительно mmap для выделений.

При достижении ммапом границы брк будет лишь ад и погибель, твоё адресное пространство кончится. Т.е. ты вообще не читал то, о чем я говорил.

http://pastebin.com/SyAvbGpm - так дитектится реальный размер вмема. А уж потом, если тебе интересны лимиты - ты берёшь max() от обоих выхлопов, но не раньше.

cat /proc/cpuinfo | grep "address sizes"

Не разумно ли использовать этот же механизм для приемки этих ограничений?

Ты реально не понимаешь какой бред ты несёшь? Понимаешь эти ограничения не лимитированы разумными рамками - ну получишь ты унлимит - что ты будешь делать? Даже на 32битном убожестве, если ты будешь полагатся на эти лимиты - ты сдохнешь ещё до тог, как их достигнешь. Ты это понимаешь?

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

Пусть покажет выхлоп RLIMIT_AS и RLIMIT_DATA на своём 32битном убожестве, либо если оно есть у тебя - покажи и ты. Потом мы посмотрим как далеки их выхлоп от реального.

Плюс где-то glibc есть интерфейс к meminfo - оно уже хоть что-то действительно реальное показывает.

Эти нули, которые кукарекают на мой код. Что конкретно там g-code? Опиши мне, только не убегай - побереги свйо попец.

Я даже устрою тебе тестик, что ты там найдёшь чего-то такого:

#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char *argv[])
{
    char *p = malloc(20);
    char *q = malloc(4096);
    char *azazaz = malloc((size_t)4096*1024*1024);

    printf("%p\n%p\n%p\n", p, q, azazaz);
    return 0;
}

0x7fa808c03900
0x7fa809003200
0x10173c000

Вместо тысячи слов...

Ну, что ты этим хотел сказать. Ну даже если в обратном порядке и? Что конкретно это отменяет? Выкатывай strace, uname. Посмотри на разность между p и q. Это даже не глибц, это маздай?

q,p - имеют шаг явно намного больше твоего запроса - т.е. это либо ущербанская реализация маллока с шагом на ?ммапе, причем шаг рандомно-ущербанский.

Возможно ты хотел показать, что адреса идут вверх, но это не имеет значения. brk() так же зафейлится на твоём ммапе и без разницы в какую сторону он пойдёт. На 64битной адресации можно взять середину и идити вверх - на 32битной ты обосраёшься.

Да и вообще причем тут твой обосранный маллок?

Ну и понятно, что ты обосрался и заигнорил все посты. Осиль void и суфиксы, животное.

Я жду вменяемого ответа на мой пост, и аргументации к твоего выхлопу о говнокоде и прочее.

Возможно ты в очередной раз сел в лужу, а мне уже не так интересно в очередной раз это обсуждать. Если тебе невдомек, почему 20 байт и 4к выделяются в разных областях кучи, то чо скажи с тобой еще мусолить.

ты обосрался и заигнорил все посты

У меня кроме лора есть еще занятия, и я не мониторю в нетерпении твои ответы. А то, что тебе не удобно общаться в таком формате — твоя школопроблема. Не можешь язык свой грязный за зубами держать, сиди в ридонли, и не надо срать из под анонимуса — до тебя он вполне годные ответы спрашивал.

Сел в лужу какразтаки ты, ты не предоставил ни strace, ни uname -a. Ты просто балаболишь, причем балабольство твоё недоказуемо. Ты так и не смог ответить на вопрос: «что ты этим хотел сказать?», ибо ты ничего не хотел сказать.

Если тебе невдомек, почему 20 байт и 4к выделяются в разных областях кучи, то чо скажи с тобой еще мусолить.

Т.е. ответить тебе нечего. Вопервых это говно - раз, во вторых это не глибц - два. В третьих - причем тут вообще где они там «выделяются», если разговор был не о том? Т.е. ты съехал с темы на совершенно ущербанские пруфцы с маздайки, которая тут никому: а) не интерсно, б) - это онтопик, в) это не меняет никак того, о чем я тут говорил. А тебе съехать было мало - ты ещё и начал кукарекать про «что с тобой ещё мусолить».

У меня кроме лора есть еще занятия,

Это тебе не мешает нести явный бред на лоре, сливаться, а потом отвечать совершенно на другие темы + опрадывать это «ещё есть занятия».

А то, что тебе не удобно общаться в таком формате — твоя школопроблема.

Ты нулёвая кукарекушка была обоссана, иначе ты бы так и продолжил болтать про rlimit() - ты свичнулся с разговора про rlimit на хрен знает что - ты врёшь. Всё это жалкие отмазки обоссанного нуля.

Не можешь язык свой грязный за зубами держать

Я не держу свой язык в разговоре со всяким сбродом. Ты потерял своё лицо, когда слился из темы - ты ничто и давать какие-то поблажки жалкому ничтожеству я не собираюсь. Пытался бы ты что-то понять - тогда я бы тебе сделал скидку, да даже если бы ты не юлил тоже.

сиди в ридонли, и не надо срать из под анонимуса — до тебя он вполне годные ответы спрашивал.

Кто спрашивал? Какие ответы? Ты обрался с rlimit"ами. Ты несознательно(по причине своей нулёвости и веры в противоположное) наврал тс"у - а т.е. как обычный нуль выбрал самый примитивный путь даже не пытаясь понять того, о чем пацаны говорили выше потреду.

Возможно ТС почитает наш спор и если у него чуть больше, чем 0 мозгов - он поймёт, что: а) питух спорящий со мной идит, б) он пойдёт посмотрит на выхлоп rlimit"ов и прийдёт к тому же выводу - питух спорящий со мной идиот. в) почитает матчасть и попробует понять: а) что ему вообще надо, б) перечитает тред и увидит рассуждения на тему и прийдёт к тому самому выводу - питух спорящий со мной тотальный идиот. Ударит себя по роже фейспалмом и скажет: «молодец анонимус». После этого пойдёт и напишет нормальный код.

А маздайская шваль так и будет кукарекать.

:) ай, поднял настроение. Если это успокоит ваше царское негодование, в унейме есть слово дарвин, а getrlimit я ни разу не юзал, просто загуглил для тса, потому что как-то натыкался на него. И таки да, если он протух в твоем дистре или в глибце, это проблема дистра или глибца. Остальной бред и джикоде, который, как по составу, так и по целям, пролетает как фанера над парижем, ты прав, я оставлю без комментариев — микротест все сказал без тысяч и слов ;)

ты в runtime можешь дернуть mmap и попросить хоть все адресное пространство,

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

механизм overcommit memory позволит тебе выделить память, но в момент работы с ней, скорее всего, твое приложение будет убито OOM Killer

Вообще идея виртуальной памяти, как бы, идеологически, подсказывает что память это почти безграничный ресурс. Т.е. он у тебя есть, но его безгранично много.

Насколько много? Ты не можешь знать, и либо ресурсов машины хватит на твою программу, либо нет.

тебе нужно не это. тебе нужно узнать сколько оперативки установлено и сколько swap-а доступно. за сим, рекомендую глянуть сорц какой-нибудь утилиты типа free

Captain obvious to the rescue!

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

Ну если не будет overcommit то не будет выделения памяти как все привыкли.

Вы знаете системы где overcommit таки вырублен? Назовете? Можете попробовать вырубить его на своей системе :)