LINUX.ORG.RU

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

 , , ,


0

2

Приветствую,

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

dma_map_single
. Там есть такие слова:

Memory coherency operates at a granularity called the cache line width... Therefore, it is recommended that driver writers ... only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries).

Вопрос: какая функция ядра гарантиурет, что память выделена по границе страницы? Вроде как kmalloc больше оптимизирован на выделение памяти объектам размером меньше страницы.

★★

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

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

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от prischeyadro

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

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

ebantrop ()
Ответ на: комментарий от tailgunner

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

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

ebantrop ()
Ответ на: комментарий от ebantrop

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

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от prischeyadro

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от Sorcerer

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от ebantrop

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от prischeyadro

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

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

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

dma_map_single

anonymous ()
Ответ на: комментарий от Iron_Bug

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

true_admin ★★★★★ ()
Ответ на: комментарий от prischeyadro

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

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

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

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

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

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

mv ★★★★★ ()
Ответ на: комментарий от prischeyadro

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от mv

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

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
получается, что два разных источника пишут в один кэш-лайн, а когда он обновляется, часть данных теряется. но это не на всех процах.

Iron_Bug ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

cruz7 ★★ ()
Последнее исправление: cruz7 (всего исправлений: 1)
Ответ на: комментарий от prischeyadro

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от prischeyadro

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

anonymous ()
Ответ на: комментарий от cruz7

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

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

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

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

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.