память выровнена по границе страницы

get_free_page точно, и, наверное, kmalloc(достаточно_много).

Если собрался писать драйвера для линукса, почитай хорошую книгу Linux Device Drivers. (После этого ненадолго прервись и подожди осени, когда выйдет её 4-е издание, лол.)

Нужные тебе функции описаны в главе 8. Конкретно тебе нужна __get_free_pages

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

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

Почему? В чем может быть проблема с кэшем?

наверное, kmalloc(достаточно_много).

«достаточно_много» не даст.

В чем может быть проблема с кэшем?

Девайс по DMA записал в память одно, процессор читает из неё другое. Процессор записал в память одно, девайс читает из неё другое. Может, есть какое-то простое решение без бубна, конечно. Или это я свой опыт с Xilinx Zynq неоправданно на всё проецирую.

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

А барьеры разве не могут помочь?

а как ты про барьеры будешь рассказывать девайсу на шине? он херачит в память по физ. адресу. а проц тем временем занимается своими делами.

Или это я свой опыт с Xilinx Zynq неоправданно на всё проецирую.

О, интересно. А volatile не помогает?

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

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

конечно есть - ТС тебе какбы намекает

читаю https://www.kernel.org/doc/Documentation/DMA-API.txt секцию «Part Id» про функцию

dma_map_single

Это называется cache coloring. Слава богу это почти не используется.

Нашёл вот такое: http://stackoverflow.com/questions/7132284/dma-cache-coherence-management

Девайс по DMA записал в память одно, процессор читает из неё другое.

Вставь load fence перед чтением.

Процессор записал в память одно, девайс читает из неё другое.

Вставь store fence после записи. Или инвалидируй кэшлайн, если шина, контроллер памяти и кэш слабо между собой связаны в используемой архитектуре.

Может, есть какое-то простое решение без бубна, конечно. Или это я свой опыт с Xilinx Zynq неоправданно на всё проецирую.

Наверняка в мурзилке по ARM есть best practices, как с DMA работать.

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

не всегда этого достаточно.

Even if those classes of memory could physically work with DMA, you'd need to ensure the I/O buffers were cacheline-aligned. Without that, you'd see cacheline sharing problems (data corruption) on CPUs with DMA-incoherent caches. (The CPU could write to one word, DMA would write to a different one in the same cache line, and one of them could be overwritten.)

https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt
получается, что два разных источника пишут в один кэш-лайн, а когда он обновляется, часть данных теряется. но это не на всех процах.

get_free_page точно, и, наверное, kmalloc(достаточно_много).

Да, про get_free_page мне известно. В драйвере, который мне достался и с которым я сейчас работаю, выделен пул буферов через kmem_cache и оттуда черпаются буферы для dma операций; ведь вроде kmem_cache состоит из 1 и более slab, каждый slab это 1 и более contiguous страницы, соответственно kmem_cache_alloc должен бы возвращать по границе страницы? Или таки это платформенно зависимо?

PS. Что имеется в виду под «достаточно_много»

на х86 такой проблемы нету, это чисто армовский прикол.

до dma_sync_*_for_{cpu,device} ты книжку так и не дочитал походу?

каждый slab это 1 и более contiguous страницы, соответственно kmem_cache_alloc должен бы возвращать по границе страницы?

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

PS. Что имеется в виду под «достаточно_много»

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