2010-07-28 22 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); 
} 

所以是的,它通過並讀取整個文件。問題是我需要在此過程中(12M/8k)發射1536次的dtrace探頭。即使我計算了所有的fbt:mach_kernel:vm_fault::探針和所有的vminfo :::探針,我也沒有達到500,所以我知道我沒有找到正確的探針。

任何人都知道在哪裏可以找到dtrace探針,當頁面從磁盤發生故障時會觸發?

UPDATE:

在起飛的機會,問題是,有一些智能預取的標準輸入輸出功能的時候,我試過如下:

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實時,其中10s是用戶,其餘是系統時間 - 頁面錯誤,我猜),但仍然會產生五分之一的錯誤,如我所料。

爲了好奇,時間增加並不是由於循環開銷和鑄造(char到int)。執行這些操作的代碼版本需要0.07秒。

+0

......以及後續問題......爲什麼dtrace問題總是以「唧唧喳喳唧唧聲」類別結束?我懷疑這是因爲dtrace探針的唯一真實文檔位於內核源代碼中,而OS X只是少量地發佈。這就是爲什麼我更喜歡在solaris機器上使用dtrace,所以我可以從Open Solaris中挖掘出我需要的東西。 – Sniggerfardimungus 2010-07-28 16:56:25

+0

你也可以在FreeBSD上試試'dtrace' :) – 2010-08-13 19:02:21

回答

1

不是一個直接的答案,但它似乎等同於磁盤讀取和頁面錯誤。它們不一定相同。在您的代碼中,您正在將文件中的數據讀取到小型用戶內存塊中,因此I/O系統可以將文件以任何方式讀取到緩衝區/ VM緩存中,並以它認爲合適的大小進行讀取。我可能在這裏錯了,我不知道達爾文是如何做到這一點的。

我覺得比較可靠的測試是將mmap(2)整個文件放到進程內存然後再去觸摸每一頁就是那個空間。

+0

爲什麼我假設讀取會通過斷層強制加載,我不知道。你已經死於mmap了,我應該知道的更好。 – Sniggerfardimungus 2010-08-14 06:05:58

0

假定操作系統在作爲單獨操作觸摸的每個頁面都會出錯(因此,如果您觸摸N個頁面,您將看到DTrace探針觸發N次)是有缺陷的;大多數聯合國* Xes將執行某種預讀或預錯,並且您不太可能獲得與頁面完全相同的呼叫次數。即使直接使用mmap()也是如此。

準確的比率也可能取決於文件系統,因爲預讀和頁面集羣實現和閾值對於它們都不太可能相同。

如果您直接使用mmap,然後應用madvise(MAD​​V_DONTNEED)或類似和/或使用msync(MS_INVALIDATE)清除整個範圍,那麼您可能會強制執行每頁錯誤策略。

1

我最近也遭受過同樣的痛風。我沒有我的DTrace腳本或測試程序可用,但我會給你以下建議:

1.)通過Amit Singh開始使用OS X Internals,並閱讀有關虛擬內存的8.3節將幫助您選擇DTrace探針的正確參考框架)。

2.)通過Brendan Gregg/Jim Mauro開始使用Solaris性能和工具。閱讀虛擬內存部分,並密切關注使用vminfo提供程序的示例DTrace腳本。3.)OS X肯定是從文件系統預取大塊頁面,並且你的測試程序正在進行這種優化(因爲你正在順序讀取)。有趣的是,Solaris不是這種情況。嘗試隨機訪問大數組來擊敗預取。