mmap + madvise верно использую?

Ты уже 2 с половиной года не можешь организовать свой видеостриминг, может он и не нужен раз всё это время тебе без него норм живётся?

в смысле не можешь? новые задачи появились, которых раньше не было

неверно, еще и mmap EINVAL возвращает

читайте маны, они рулят

По ошибке то понятно в мане написано, тут какая статейка нужна на применение.

1. У тебя mmap с ненулевым offset. Это нормально. Это значит надо отобразить в память не весь файл, а начиная с указанного смещения в файле. Сколько байт надо отобразить – задаёт partition_size.

2. Байт (uint8_t*)md + n в памяти это байт offset + n в файле.

3. fwrite пишет в stdio буфер в юзерспейсе. fflush сбрасывает stdio буфер в блочный кэш ядра. Отмапленный таким образом регион это блочный кэш ядра. Если один поток выполняет fflush, а другой поток читает отмапленый регион, то это data race.

спасибо, т.е. madvise/munmap корректно выполнять только на размер partition_size без offset

другой поток читает отмапленый регион

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

а по этой ошибки кто нибудь знает где размер страницы в системе посмотреть-задать? чтобы понять какое там выравнивание нужно

sysconf(_SC_PAGE_SIZE) на арм тоже оказывается 4к страница

) но все равно как то туплю - если первый сектор с которого можно писать это 2048, то какой offset для mmap должен быть чтобы начать с первого байта этого сектора…

вопщим как обычно оказалось перемудрил в очередной раз высчитывая смещение через (2048 - 1) * размер_сектора + 1

ладно, вроде и так все работает, будем считать что замена read на mmap мне существенно снизило потребление памяти, а может и отклик уменьшило при старте - точно могу сказать только что код уменьшило почти в 2 раза ))

епта, а что больше 2GB нельзя mmap и нужно каждый раз смещаться???

получается нужно носитель набить на куски по 2гб и хранить массив указателей ((

Что за нездоровая сенсация? В 64-разрядном процессе можно мапить кусками больше 2 GiB.

у него какой-то арм с 512М озу, вряд ли 64битный

по конфигу верно, ось 32битная… щас может как обычно косяк в другом

Если 32-битная то не то что нельзя больше 2гб mmap, нельзя вообще больше 2гб чего угодно одновременно выделять.

так хоть бы mmap с ошибкой происходил, а то сегфолится при обращении

mmap не вернул MAP_FAILED? Похоже на ещё одну нездоровую сенсацию.

вот как то так )

причем если из 2гб адресов все работает, пока не обратиться выше

выделять

тут не понял, mmap же ничего не выделяет

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

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

Речь не про занятую память а про занятое адресное пространство процесса.

mmap (без флага MAP_POPULATE) не выделяет физические страницы, но он выделяет место в адресном пространстве процесса. Если места в адресном пространстве процесса не достаточно, он должен вернуть MAP_FAILED.

Можно форкнуть несколько процессов, и в каждом смапить разные куски файла. Но это дурацкая идейка кмк.

т.е. смысла нет бить диск на куски по 2гб и хранить адреса после ммап?

Ты не сможешь отмапить больше одного 2 GiB куска в одно 32-битное адресное пространство. Вот пример. Программка мапит куски размером 1 GiB, пока mmap не вернёт MAP_FAILED:

#include <fcntl.h>
#include <signal.h>
#include <stddef.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>

int main(int argc, char** argv)
{
    int fd;
    void* base;
    sigset_t set;
    int signo;
    size_t size;
    off_t offset;

    if (argc != 2) return 1;

    size = 0x40000000; /* 1 GiB */
    offset = 0;
    for (;;) {
        fd = open(argv[1], O_RDONLY | O_CLOEXEC);
        base = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, offset);
        close(fd);
        if (base == MAP_FAILED)
            break;
        printf("base=%p\n", base);
        offset += size;
    }

    sigemptyset(&set);
    sigaddset(&set, SIGINT);
    sigwait(&set, &signo);
    return 0;
}

Компилируем в 32-битный бинарник (чтобы при запуске программки получился 32-битный процесс с 32-битным адресным пространством), и запускаем:

$ gcc -Wall -Wextra -pedantic -m32 -o map map.c
$ ./map /dev/nvme0n1p4
base=0xb7d0a000
base=0x77d0a000
base=0x37d0a000

Программа смогла отмапить только 3 GiB. Четвёртый одногигабайтный кусок отмапить уже не удалось. 32-битное адресное пространство имеет размер 4 GiB, а часть его уже занята (кодом, данными и стеком программы).

а у меня так

pi@NanoPi-NEO-Core:~$ sudo ./test /dev/mmcblk1
base=0x76e2f000
base=0x36e2f000

и никакого брейка нет, просто висит

Там в конце программы sigwait, в нём и висит. Чтобы можно было в procfs посмотреть мапинги процесса. Не веришь, что висит в sigwait? Закомментируй его, перекомпилируй и перезапусти.

Я запускал на 64-битном x86_64 (64-битное ядро, 32-битный процесс). В этом случае процессу доступны все 4 GiB адресного пространства. Код и данные программы занимают младшие адреса, стек – старшие. Между ними дырка для mmap-а. У меня та дырка заканчивается видимо на 0xb7d0a000 + 0x40000000 = 0xf7d0a000.

У тебя 32-разрядное ядро и 32-разрядный процесс. Процессу доступны 3 GiB из адресного пространста, верхний 1 GiB зарезервирован для ядра. (Когда процесс входит в ядро сисколлом, ядру нужно иметь доступ одновременно к собственным коду и данным, и к данным процесса, вызвавшего сисколл. Поэтому на 32-битных системах верхний 1 GiB адресного пространства недоступен процессу.)

Поэтому у тебя доступное адресное пространство заканчивается на 0xc0000000, а mmap-дырка заканчивается на 0x76e2f000 + 0x40000000 = 0xb6e2f000.

спасибо большое за ликбез

што ж буду откатываться обратно на read в кучу (

прикола ради

#include <fcntl.h>
#include <signal.h>
#include <stddef.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdint.h>

int main(int argc, char** argv)
{
    int fd;
    void* base;
    sigset_t set;
    int signo;
    uint64_t size;
    off_t offset;

    if (argc != 2) return 1;

    size = (uint64_t)1024 * 1024 * 1024 * 10;
    offset = 0;
    for (;;) {
        fd = open(argv[1], O_RDONLY | O_CLOEXEC);
        base = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, offset);
        close(fd);
        if (base == MAP_FAILED)
            break;
        printf("base=%p\n", base);
        offset += size;
    }

    return 0;
}

base=0x36eb8000

Второй аргумент mmap имеет тип size_t. У 32-битных процессов size_t 32-битный. У тебя здесь произошёл молчаливый каст из uint64_t в size_t, который отрезал старшие биты от 10 GiB = 10*1024*1024*1024 = 0x2'8000'0000, получилось 0x8000'0000, т.е. 2 GiB. Один 2 GiB кусок в 32-битный процесс смапить можно.

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

хе хе, добавь -Wconversion -Werror, и будут тебе ошибки компиляции.

да у меня педантик стоит и ничего не сказало (

-Wall -pedantic -O3

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

хе хе, вроде смещать mmap кусками по 20мб (в расчете на 100 коннектов) не сильно хуже, на том и остановлюсь

еще раз спасибо за помощь всем.

… У тебя 32-разрядное ядро и 32-разрядный процесс. Процессу доступны 3 GiB из адресного пространста, верхний 1 GiB зарезервирован для ядра

зависит от, на примере linux-3.10.33 доступны разделеняи памяти как 3G/1G user/kernel split, 2G/2G user/kernel split и 1G/3G user/kernel split

да у меня педантик стоит и ничего не сказало (

добавь -Wextra -Werror

спасибо, крутяк