LINUX.ORG.RU

[x86_64] Виртуальная адресация


1

1

Добрый день.

Читаю про адресацию в Линуксе, но никак не могу понять почему логический (линейный) адрес в ядре _всегда_ соответствует физическому, только смещен на константу. Читал, что это должно как-то увеличивать скорость, но ведь все равно адрес преобразовывается или через таблицу страниц или через tlb и, как мне кажется, ему должно быть тогда все равно. Смысл вижу только, если память будет использоваться при вводе/выводе (DMA, например).

И почему ядро старается разместиться в ZONE_NORMAL, а не в ZONE_HIGH, например? Ведь адреса-то виртуальные.

Всем спасибо за помощь)

DesertFox
() автор топика
Ответ на: комментарий от Murr

>Там, как и на alpha, буфер трансляций заполняется программно?

Я не очень долго работал с V9, поэтому всех тонкостей не скажу.

В целом ситуация такая. У них там буфер трансляций, который заполняется по исключению (sun4v_itsb_miss и sun4v_dtsb_miss). Он используется только для пользовательских адресов. Сам TSB лежит в оперативной памяти (и для каждого процесса он свой).

TSB — это таблица tte и tag, ограниченного размера. Если искомый адрес (которого нет в TLB) находится в TSB (по тэгу), то загружается он. Если нет, ищется в таблице страниц, оттуда загружается в TSB (возможно, вытесняя одну из записей).

Примерно так.

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

Спасибо, примерно понятно. А что собой представляет таг? Если он уникальным образом транслируется, то это что-нибудь вроде вирт.адрес+tid?

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

http://www.fujitsu.com/downloads/PRMPWR/JPS1-R1.0.4-Common-pub.pdf

Страница 440

Таг — это вирт адрес, номер контекста и признак глобальности тага.

Дата — это вторая колонка TSB.

Действительно, таблица страниц аппаратуре побоку.

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

> Наша цель найти пустую запись в таблице страниц,

те, нам нужно написать менеджер виртуального пространства/
адресов

У нас 256 TB виртуального адресного пространства, думаю

место для 2 записей подряд там найдется.



«и вы напрасно думаете, что это просто. это очень не
просто» (с) ;)

но это только начало. потом нам нужно будет flush tlb
на всех cpu.

но и это только вершина айсберга.

ладно, это thread уже помечен как «solved». на итог, нам
лучше решать эту проблему в «другом месте», и эти места
уже обсуждались.

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

данном alloc_pages(). sl*b работает поверх.

поэтому «с точки зрения buddy allocator они не являются
парой» не имеет смысла.

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

> Вот оно в чем дело... DMA...

да нет же!

то есть, и это тоже. но это «детали». как я уже говорил,
можно временно забыть про ZONE_*, чтобы упростить картину.

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

>данном alloc_pages(). sl*b работает поверх.


поэтому «с точки зрения buddy allocator они не являются
парой» не имеет смысла.

Вы продолжаете говорить загадками. kmem-аллокатор работает поверх buddy allocator, поэтому если buddy allocator не сможет выделить две страницы, то не сможет и kmem.

В свою очередь buddy allocator не сможет выделить две свободные смежные страницы, если они не являются парой, или, иначе, если они не натуральным образом выровнены.

Появился смысл?

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

> Вы продолжаете

так мы на «ты» или на «Вы» ?

kmem-аллокатор работает поверх buddy allocator,


что такое kmem-аллокатор? kmem_cache_alloc ?

В свою очередь buddy allocator не сможет


мы говорим про alloc_pages, а buddy allocator работает
поверхюъ.

Появился смысл?


пока нет, но я опять пьяный. может, поэтому.

еще раз. речь шла о alloc_pages(order). где здесь
buddy allocator?

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

>Появился смысл?

На всякий случай попробую еще проще. Помимо физической фрагментации вроде 1010 существует неразрешимая для алгоритма фрагментация вроде 1001. Ее можно победить линейным сканированием за счет сильной потери производительности, но проблема в той или иной форме имеется.

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

>еще раз. речь шла о alloc_pages(order). где здесь

buddy allocator?

Ну привет. alloc_pages() - это и есть buddy allocator. Никакого buddy аллокатора поверх него нет.

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

>Таг — это вирт адрес, номер контекста и признак глобальности тага.

Ага. Очень похоже на родной 21264. :-)

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

> Неужто глаз режет? ;)

не то, что бы ;)

просто меня тут долго отучали обращаться на «вы».

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

>Не привык не форуме обращаться на «вы».

s/вы/ты/

Сплю уже. :(

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

> alloc_pages() - это и есть buddy allocator

а. тогда я просто терминологии не знаю. пусть.
я думал, ты про sl*b.

но. тогда я не понимаю, что значит

> Кроме того, нельзя выделить две страницы, если с

> точки зрения buddy allocator они не являются парой.


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

> но. тогда я не понимаю, что значит



> Кроме того, нельзя выделить две страницы, если с


> точки зрения buddy allocator они не являются парой.



iow.

я этот код не понимаю, и читать его сейчас некогда. но
мне казалось, что __free_one_page() всегда старается
«склеить» страницы и увеличить order.

те, я не вижу, каким образом вся свободная память в зоне
может попасть в zone->free_area[0] (если, конечно, у нас
нет фрагментации).

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

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

>мне казалось, что __free_one_page() всегда старается

«склеить» страницы и увеличить order.

Пытаться-то он пытается, но легко может обломаться.

см. пример из http://www.linux.org.ru/jump-message.jsp?msgid=6042103&cid=6043755

Возьмем карту 1101, освободим страницу с индексом 1, так что получится 1001. С т.з. физической фрагментации после этого есть две смежные страницы, но с точки зрения алгоритма нет.

в __free_one_page вызов __page_find_buddy вернет страницу с индексом 0, а не с индексом 2. page_is_buddy вернет 0, т.к. PageBuddy(0) будет 0 (страница используется).

Цикл выйдет на первой итерации, не пометив в order=1 ни одной свободной ячейки.

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