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?
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. –