2010-09-21 11 views
7

Nella nostra applicazione stiamo eseguendo su un server Xeon doppio con memoria configurata come 12 gb locale per ciascun processore e un bus di memoria che collega i due Xeon. Per motivi di prestazioni, vogliamo controllare dove allociamo un grande blocco di memoria (> 6gb). Di seguito è riportato il codice semplificato -Tempo di accesso alla memoria lento con VirtualAllocExNuma su Windows 7/64

DWORD processorNumber = GetCurrentProcessorNumber(); 
UCHAR nodeNumber = 255; 
GetNumaProcessorNode((UCHAR)processorNumber, &nodeNumber); 
// get amount of physical memory available of node. 
ULONGLONG availableMemory = MAXLONGLONG; 
GetNumaAvailableMemoryNode(nodeNumber, &availableMemory) 
// make sure that we don't request too much. Initial limit will be 75% of available memory 
_allocateAmt = qMin(requestedMemory, availableMemory * 3/4); 
// allocate the cached memory region now. 
HANDLE handle = (HANDLE)GetCurrentProcess(); 
cacheObject = (char*) VirtualAllocExNuma (handle, 0, _allocateAmt, 
      MEM_COMMIT | MEM_RESERVE , 
      PAGE_READWRITE| PAGE_NOCACHE , nodeNumber); 

Il codice così com'è funziona correttamente con VS2008 su Win 7/64.

Nella nostra applicazione questo blocco di memoria funziona come un archivio di cache per oggetti statici (1-2mb ea) che sono normalmente memorizzati sul disco rigido. Il mio problema è che quando trasferiamo i dati nell'area della cache usando memcpy, ci vuole> 10 volte più a lungo che se assegnassimo memoria usando new char[xxxx]. E nessun altro codice cambia.

Non siamo riusciti a capire perché questo sta accadendo. Qualche suggerimento su dove guardare?

risposta

7

PAGE_NOCACHE è un omicidio perfetto, disabilita la cache della CPU. Era intenzionale?

+1

No. Non è quello che intendevo. Avevo pensato che disabilitato il caching del disco del blocco di memoria, non della CPU. Questo ha risolto la maggior parte dei miei problemi di prestazioni. Grazie. –

Problemi correlati