2010-07-28 5 views
3

Я пишу документ о сбое страницы и пытаюсь получить некоторые конкретные числа для работы, поэтому я написал простую программу, которая читает 12 * 1024 * 1024 байта данных. Легко:Какой (OS X) датчик dtrace срабатывает при сбое страницы с диска?

int main() 
{ 
    FILE*in = fopen("data.bin", "rb"); 
    int i; 
    int total=0; 
    for(i=0; i<1024*1024*12; i++) 
    total += fgetc(in); 
    printf("%d\n", total); 
} 

Так что да, он проходит и читает весь файл. Проблема в том, что мне нужен датчик dtrace, который будет срабатывать 1536 раз в течение этого процесса (12M/8k). Даже если я считаю все fbt: mach_kernel: vm_fault *: пробники и все vminfo ::: пробники, я не нахожу 500, поэтому я знаю, что не нахожу правильных зондов.

Кто-нибудь знает, где я могу найти датчики dtrace, которые срабатывают при сбое страницы с диска?

UPDATE:

На случае, если проблема была, что есть некоторая интеллектуальная упреждающая выборка происходит в STDIO функций, я попытался следующее:

int main() 
{ 
    int in = open("data.bin", O_RDONLY | O_NONBLOCK); 
    int i; 
    int total=0; 
    char buf[128]; 
    for(i=0; i<1024*1024*12; i++) 
    { 
    read(in, buf, 1); 
    total += buf[0]; 
    } 
    printf("%d\n", total); 
} 

Эта версия занимает гораздо больше времени (42s в реальном времени, 10 из которых были пользователем, а остальное было системным временем - ошибки страницы, я предполагаю), но все же генерирует одну пятую столько ошибок, сколько я ожидал.

Для любознательных, увеличение времени не связано с накладными расходами и литьем цикла (char to int.) Версия кода, выполняющая только эти действия, занимает 0,0 секунд.

+0

... и последующий вопрос ... почему вопросы dtrace всегда попадают в категорию «звук чирикающих сверчков»? Я подозреваю, что это связано с тем, что единственная реальная документация для dtrace-зондов находится в источнике ядра, который OS X выпускает только экономно. Вот почему я предпочитаю использовать dtrace в ящике солярия, поэтому я могу выкопать то, что мне нужно, от Open Solaris. – Sniggerfardimungus

+0

Вы также можете попробовать 'dtrace' на FreeBSD :) –

ответ

1

Непосредственный ответ, но, похоже, вы приравниваете чтения дисков и ошибки страниц. Они не обязательно одинаковы. В вашем коде вы читаете данные из файла в небольшой фрагмент памяти пользователя, поэтому система ввода-вывода может считывать файл в кеш-буфер/VM любым способом и по размеру, который он считает нужным. Возможно, я ошибаюсь, я не знаю, как Дарвин это делает.

Я думаю, что более надежным тестом будет mmap(2) весь файл в память процесса, а затем коснитесь каждой страницы, это пространство.

+0

Почему я предполагал, что чтение приведет к нагрузке через сбой, я понятия не имею. Ты мертв с ммэпом, и я должен был знать лучше. – Sniggerfardimungus

0

Предполагается, что операционная система будет виновата в каждой странице, на которую затрагивается отдельная операция (и поэтому, если вы коснетесь N страниц, вы увидите, что огонь DTrace-зонда N раз ошибочен; большинство UN * Xes выполнит какую-то проверку или предварительную проверку, и вы вряд ли получите ровно столько же вызовов, сколько у вас есть страницы. Это так, даже если вы используете mmap() напрямую.

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

Возможно, вы можете принудительно выполнить политику сбоев на странице, если вы используете mmap напрямую, а затем примените madvise (MADV_DONTNEED) или аналогичные и/или очистите весь диапазон с помощью msync (MS_INVALIDATE).

1

В последнее время я был с тем же самым рэтом. У меня нет моих сценариев DTrace или тестовых программ, доступных сейчас, но я дам вам следующий совет:

1.) Получите доступ к OS X Internals от Amit Singh и прочитайте раздел 8.3 по виртуальной памяти (это вы попадете в правую систему отсчета для выбора зондов DTrace).

2.) Получите удовольствие от работы и инструментов Solaris от Брендана Грегга/Джима Мауро. Прочтите раздел о виртуальной памяти и обратите пристальное внимание на примеры скриптов DTrace, которые используют поставщик vminfo.

3.) OS X определенно предварительно загружает большие куски страниц из файловой системы, и ваша тестовая программа играет именно в эту оптимизацию (поскольку вы читаете последовательно). Интересно, что это не относится к Solaris. Попробуйте случайно получить доступ к большому массиву, чтобы победить предварительную выборку.