Тебе религия не позволяет ознакомиться хотя бы с LDD3?

Я к чему — сильно много общих вопросов задал

Ядро может выделить только до 4 мб физически линейной памяти. Дальше либо девайс должен уметь scatter-gather dma и нужный объём памяти ему набивать постранично, либо можно извернуться и получить больше 4 линейных мб, но этого в LDD нет.

Ответы на остальные вопросы можно найти в LDD.

+

LDD - это книга Linux Device Drivers

может у тебя это memio бары?, тогда можно через /dev/mem к ним обращаться

тут вообще много тем подобных было

Kernel Memory Allocation

DMA для PCI в режиме Bus Master (комментарий)

либо можно извернуться и получить больше 4 линейных мб, но этого в LDD нет.

Можешь поделиться как это сделать? Ссылкой или кодом или словами описать, что к чему. Реально очень нужно. Спасибо.

Если твоя железка не умеет scatter/gather - она либо говно, которое нужно выкинуть, либо ты должен поговорить с разработчиками, чтобы они добавили такую возможность.

Для DMA в/из userspace не нужны ни kmalloc, ни mmap.

Для DMA в/из userspace не нужны ни kmalloc, ни mmap - кажется get_user_pages(...)

кажется get_user_pages(...)

Да. Потом virt_to_page, sg_set_page, и дескрипторы В/В. Но без scatter/gather в железке это не имеет смысла.

Можешь поделиться как это сделать? Ссылкой или кодом или словами описать, что к чему. Реально очень нужно. Спасибо.

Товарищ buddy, который allocator, делит память кусками максимум по 1024 страницы, т.е. 4 мб. Если у него много раз спросить кусок по 4 мб, то многие куски будут иметь общую границу в физической адресации. Таким образом можно найти непрерывный набор страниц подходящей длины, подготовить его к использованию, освободить остальные, неподходящие страницы, io_remap_pfn_range в юзерский процесс, и всё.

Мы таким лыком успешно выделяем своему девайсу сотни мегабайт/гигабайты памяти в первых 4 гб (девайс sgdma сознательно не умеет, т.к. это не low latency). Если драйвер грузится не сразу после загрузки системы, то могут возникнуть проблемы с фрагментированием памяти, решаемые её компактированием, либо ребутом.

http://pastebin.com/HaCgMjSs

Буду разбирать. А вот, то, что память выделяется в 4ГБ диапазоне как-то преодолеваемо? Просто имеющийся девайс может работать с 64-битными адресами.
Если в строчке
addr = __get_free_pages(GFP_DMA32, 10);
указать набор флагов по или прокатит или нет?
Как я понял, код по ссылке реализует указанный Вами алгоритм?
За ссылку и разъяснения спасибо.

Буду разбирать. А вот, то, что память выделяется в 4ГБ диапазоне как-то преодолеваемо?

Да.

Просто имеющийся девайс может работать с 64-битными адресами. Если в строчке addr = __get_free_pages(GFP_DMA32, 10); указать набор флагов по или прокатит или нет?

Да.

Как я понял, код по ссылке реализует указанный Вами алгоритм?

Да.

Выделяя много кусков памяти подряд в ядре я тоже заметил, что они имеют адреса идущие друг за другом, т.е. фактически непрерывны более большие объемы. Но у Вас уже написана функция. Спасибо.

1.Правильно я понимаю, что таким образом выделив один раз при загрузке большой объем памяти, можно потом получать на него указатель из user-space много раз, когда это потребуется (у меня приложение может много раз запускаться и закрываться во время работы)? Все это выполняется через mmap().

2.Другой вопрос - если этих банков памяти будет много (32 или любое другое число), как выполнить mmap() для всех них? Например, задавая offset при вызове?

3.Для чего выполняется SetPageReserved() ? Для того, чтобы страницы всегда оставались в памяти и не освобождались через своп на диске?

4.В LDD3 говорится про dma_alloc_coherent() - выделение с помощью этой, как я понял, ничем не отличается?

Еще в LDD3 упоминается про alloc_bootmem(), но ее использование не рекомендуется.

1.Правильно я понимаю, что таким образом выделив один раз при загрузке большой объем памяти, можно потом получать на него указатель из user-space много раз, когда это потребуется (у меня приложение может много раз запускаться и закрываться во время работы)? Все это выполняется через mmap().

Правильно реализовать в драйвере char-девайс, у которого есть ioctl, через которые юзерспейс просит драйвер замапить ему в адресное пространство dma-буфер. Мапится в драйвере через io_remap_pfn_range. Про детали читайте LDD.

3.Для чего выполняется SetPageReserved() ? Для того, чтобы страницы всегда оставались в памяти и не освобождались через своп на диске?

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

4.В LDD3 говорится про dma_alloc_coherent() - выделение с помощью этой, как я понял, ничем не отличается?

Нам не подходит.

Еще в LDD3 упоминается про alloc_bootmem(), но ее использование не рекомендуется.

Можно и через memmap= в параметрах ядру резервировать, но это отстой и не plug'n'play.

Правильно реализовать в драйвере char-девайс, у которого есть ioctl, через которые юзерспейс просит драйвер замапить ему в адресное пространство dma-буфер. Мапится в драйвере через io_remap_pfn_range. Про детали читайте LDD.

У меня и реализован свой char-девайс для каждой подключенной PCI платы. Но, например, ресурсы PCI отправлял в user-space через .mmap. Спасибо за совет.

Сейчас кстати, по-моему, это называется .compat_ioctl и .unlocked_ioctl.

Сейчас кстати, по-моему, это называется .compat_ioctl и .unlocked_ioctl.

Раньше ioctl ядро лочили.

Правильно реализовать в драйвере char-девайс, у которого есть ioctl, через которые юзерспейс просит драйвер замапить ему в адресное пространство dma-буфер.

O_O

И чем это лучше mmap?

И чем это лучше mmap?

Я не понял, что у ТС за mmap.

Да ТНБ с ТС, зачем

ioctl, через которые юзерспейс просит драйвер замапить ему в адресное пространство dma-буфер.

это прекрасно делается через православный mmap

это прекрасно делается через православный mmap

У нас память бьётся на несколько сегментов различного назначения, поэтому отдельные ioctl. Сия особенность затмила мой разум.

У нас память бьётся на несколько сегментов различного назначения, поэтому отдельные ioctl

Не, ты так просто не отмажешься %) Что мешало сделать mmap разных сегментов с разных адресов? Сделать несколько device node'ов?

Не, ты так просто не отмажешься %) Что мешало сделать mmap разных сегментов с разных адресов? Сделать несколько device node'ов?

Зачем? По ioctl-реквесту на задачу прямее. А танцы вокруг специальных значений address hint у mmap - это кривизна в дизайне.

По ioctl-реквесту на задачу прямее.

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

А танцы вокруг специальных значений address hint у mmap - это кривизна

offset, не address. И, как по мне, реальная кривизна - это mmap, замаскированный под ioctl.

в дизайне.

В реализации.

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

Ok, у нас не ложится.

offset, не address. И, как по мне, реальная кривизна - это mmap, замаскированный под ioctl.

Ты толкаешь ioctl, замаскированный под mmap. Замапленная память в нашем юзерском процессе - это вообще чуть ли не сайд-эффект.

addr = __get_free_pages(GFP_DMA32, 10);

А как же arm, cris, powerpc, s390 и sh?

А как же arm, cris, powerpc, s390 и sh? __get_free_pages - не портабельно? Планируется использовать драйвер на arm. Сейчас реализация или __get_free_pages или dma_alloc_coherent (на этапе ). Подскажите, на arm алгоритм указанный mv будет работать? Спасибо.

А как же arm, cris, powerpc, s390 и sh?

Нам - пофиг, ибо не то, что x86, а обязательно i7, желательно песочный мост, желательно на чипсете с ioat.

А что с этими платформами не так? На них разве buddy нет?

Планируется использовать драйвер на arm

Используй (MAX_ORDER-1) вместо всех десяток. На этом моменте мы плавно переходим к разговору о пользе дефайнов.

Ну ок, а в чём проблема?

На некоторых архитектурах не будет работать, на некоторых - будет, но неоптимально.

Хотя если тебе только для i7, то я тут не берусь судить

Если я правильно понял, то все-таки нужно выделять так:

addr = __get_free_pages(GFP_DMA32, MAX_ORDER-1);

На некоторых архитектурах не будет работать, на некоторых - будет, но неоптимально.

Не могли бы Вы пояснить это. Хотя моя цель - это x86 и x86-64, но все же интересно для общего развития.

Еще такой вопрос - как сделать, чтобы выделенный буфер был доступен только одному процессу из user-space одновременно? Как вариант, например, передавать id этого процесса (если маппировать с помощью .ioctl). По завершению этого процесса передавать другой ioctl с id и разблокировать возможность маппирования другими процессами. Но в таком случае, что делать, если процесс падает (некорректно завершается) и не разблокирует возможность маппирования?

addr = __get_free_pages(GFP_DMA32, MAX_ORDER-1);

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

NB: Здесь мы не расматриваем всякие пограничные случаи. Их можно выкинуть практически без ограничения общности. Никто в здравом уме не будет пытаться выделять себе память одновременно с разными order.

Не могли бы Вы пояснить это. Хотя моя цель - это x86 и x86-64, но все же интересно для общего развития.

Оптимально выделять большими кусками, что тут непонятного. Меньше вызовов __get_free_pages - меньше блокировок и т.д.

Выделить кусок с order >= MAX_ORDER вообще невозможно.

Еще такой вопрос - как сделать, чтобы выделенный буфер был доступен только одному процессу из user-space одновременно?

Буфер доступен тому процессу, который делает mmap. Другим недоступен. Соответственно, если есть необходимость ограничить круг пользователей, то вводишь проверку в .open или .mmap.

Но в таком случае, что делать, если процесс падает (некорректно завершается) и не разблокирует возможность маппирования?

Выделяешь память в probe. В open ограничиваешь круг пользователей одним процессом (увеличиваешь счетчик). В close уменьшаешь счетчик.

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

Думаю, проверка в open не сработает после fork.

Твоя правда. Ну счас, что-нибудь придумаем

Короче, выход такой - дополнительно добавлять флаг VM_DONTCOPY при маппировании

что-нибудь придумаем

Да что тут придумывать... придумывать тут нечего, потому что mmap наследуются при форке :) IIUC, от такого защатиться невозможно, да и стоит ли? Сделать обычный single-open «на отвяжись».

VM_DONTCOPY запрещает копировать vma при форке. См. dup_mmap

А про счетчики, которые Вы говорите, это касается счетчиков маппирования, а не открытия файла? Т.е. что-то вроде этого:

int mmap_open = 0;
void vma_open(struct vm_area_struct *vma)
{
mmap_open++;
}
void simple_vma_close(struct vm_area_struct *vma)
{
mmap_open--;
}

static struct vm_operations_struct vm_ops = {
.open = vma_open,
.close = vma_close,
};

static int mmap(struct file *filp, struct vm_area_struct *vma)
{
if (mmap_open)
return -EBUSY;

vma->vm_flags |= VM_DONTCOPY;

if (io_remap_pfn_range(vma, vma->vm_start, vm->vm_pgoff,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;

vma->vm_ops = &vm_ops;
vma_open(vma);
return 0;
}


Правильно я понимаю, что это таким образом оформленное маппирование позволит только одному процессу маппировать буфер. А если этот процесс некорректно завершится (без вызова unmap()), то буфер все равно станет доступен, т.к. будет вызвана vma_close()?

int mmap_open = 0;

Афигеть, глобальный счетчик.

io_remap_pfn_range

Как-то это не сочетается с __get_free_pages

Эти закрытия и открытия относятся к file_operations_struct, т.е. к файлу. Одновременный доступ процессов к файлу символьного устройства мне наоборот нужно иметь. Нужно, чтобы выделенный буфер единовременно мог отмаппировать только один процесс. Или я чего-то не понимаю в написанном коде.

Как-то это не сочетается с __get_free_pages

А как тогда правильно маппировать в user-space выделенный буфер?

io_remap_pfn_range

Как-то это не сочетается с __get_free_pages

Почему?

Большой кусок линейой памяти мапят обычно для DMA. Зачем при этом мапить память устройства для (очень) медленного MMIO? Я бы понял, если бы ТС хотел выделить память, сделать DMA в нее, и потом замапить ее для доступа из userspace (ну или аналогично для случая write), но для userspace мапится именно выделенная через __get_free_pages память. А io_remap* в этот сценарий как-то не вписывается.

Большой кусок линейой памяти мапят обычно для DMA. Зачем при этом мапить память устройства для (очень) медленного MMIO?

А откуда MMIO выплыло? Вроде речь как раз про DMA идёт.

откуда MMIO выплыло?

Из использования io_remap_pfn_range

Из использования io_remap_pfn_range

Ok, remap_pfn_range. Даже если это одно и то же :)

Ok, remap_pfn_range. Даже если это одно и то же :)

IIRC, зависит от архитектуры. Кроме того:

Блоки памяти могут выделяться кусочно

так что я даже не уверен в применимости remap_pfn_range здесь (да и вообще, разрешено ли использовать remap_pfn_range на результатах get_free_pages? Речь не о x86).