Любые предложения/обсуждения приветствуются!
Вопрос на самом деле краток, как заголовок, но я объясню, зачем мне нужен физический адрес.
Фон:
В эти дни я очарован кешем и многоядерной архитектурой, и теперь мне очень любопытно, как кеш влияет на наши программы в параллельной среде.
В некоторых моделях ЦП (например, в моем Intel Core Duo T5800) кэш L2 распределяется между ядрами. Итак, если программа A обращается к памяти по физическому адресу, например
0x00000000, 0x20000000, 0x40000000...
и программа B получает доступ к данным в
0x10000000, 0x30000000, 0x50000000...
Поскольку эти адреса имеют один и тот же суффикс, соответствующий набор в кэше L2 будет часто очищаться. И мы ожидаем увидеть две программы, борющиеся друг с другом, медленно считывающие данные из памяти, а не из кеша, хотя и разнесенные по разным ядрам.
Потом хочу проверить результат на практике. В этом эксперименте мне нужно знать физический адрес, а не виртуальный адрес. Но как мне справиться с этим?
Первая попытка:
Съешьте большое пространство из кучи, замаскируйте и получите определенный адрес.
Мой ЦП имеет кеш L2 с размером = 2048 КБ и ассоциативностью = 8, поэтому физические адреса, такие как 0x12340000, 0x12380000, 0x123c0000
, будут связаны с первым набором в кеше L2.
int HEAP[200000000]={0};
int *v[2];
int main(int argc, char **argv) {
v[0] = (int*)(((unsigned)(HEAP)+0x3fffc) & 0xfffc0000);
v[1] = (int*) ((unsigned)(v[0]) + 0x40000);
// one program pollute v[0], another polluting v[1]
}
К сожалению, с «помощью» виртуальной памяти переменная HEAP
не всегда непрерывна внутри физической памяти. v[0]
и v[1]
могут быть связаны с разными наборами кеша.
Вторая попытка
получить доступ к /proc/self/mem
и попытаться получить информацию о памяти.
Хм... кажется, что результаты все еще касаются виртуальной памяти.
/proc/self/maps
, но как это связано с физическими адресами? Первое поле похоже на виртуальный адрес, так связано ли полеdev
с запоминающим устройством? - person sleepsort   schedule 19.12.2012