9

コンピューターにインストールされている 192 GB RAM のうち、4 GB を超える 188 GB RAM (ハードウェア アドレス 0x100000000) が、起動時に Linux カーネルによって予約されています (mem=4G memmap=188G$4G)。データ取得カーネル モジュールは、DMA を使用してリング バッファーとして使用されるこの大領域にデータを蓄積します。ユーザー空間アプリケーションは、このリング バッファーをユーザー空間に mmap し、リング バッファーから現在の場所にブロックをコピーして、準備ができたら処理します。

memcpy を使用してこれらの 16MB ブロックを mmap 領域からコピーしても、期待どおりに動作しません。パフォーマンスは、ブート時に予約された (および後でユーザー空間にマップされた) メモリのサイズに依存するようです。 http://www.wurmsdobler.org/files/resmem.zipには、mmap ファイル操作を実装するカーネル モジュールのソース コードが含まれています。

module_param(resmem_hwaddr, ulong, S_IRUSR);
module_param(resmem_length, ulong, S_IRUSR);
//...
static int resmem_mmap(struct file *filp, struct vm_area_struct *vma) {
remap_pfn_range(vma, vma->vm_start,
    resmem_hwaddr >> PAGE_SHIFT,
    resmem_length, vma->vm_page_prot);
return 0;
}

本質的に行うテストアプリケーション（チェックを削除）：

#define BLOCKSIZE ((size_t)16*1024*1024)
int resMemFd = ::open(RESMEM_DEV, O_RDWR | O_SYNC);
unsigned long resMemLength = 0;
::ioctl(resMemFd, RESMEM_IOC_LENGTH, &resMemLength);
void* resMemBase = ::mmap(0, resMemLength, PROT_READ | PROT_WRITE, MAP_SHARED, resMemFd, 4096);
char* source = ((char*)resMemBase) + RESMEM_HEADER_SIZE;    
char* destination = new char[BLOCKSIZE];
struct timeval start, end;
gettimeofday(&start, NULL);
memcpy(destination, source, BLOCKSIZE);
gettimeofday(&end, NULL);
float time = (end.tv_sec - start.tv_sec)*1000.0f + (end.tv_usec - start.tv_usec)/1000.0f;
    std::cout << "memcpy from mmap'ed to malloc'ed: " << time << "ms (" << BLOCKSIZE/1000.0f/time << "MB/s)" << std::endl;

SuperMicro 1026GT-TF-FM109 上の Ubuntu 10.04.4、Linux 2.6.32 で、さまざまなサイズの予約済み RAM (resmem_length) に対して 16MB データ ブロックの memcpy テストを実行しました。

|      |         1GB           |          4GB           |         16GB           |        64GB            |        128GB            |         188GB
|run 1 | 9.274ms (1809.06MB/s) | 11.503ms (1458.51MB/s) | 11.333ms (1480.39MB/s) |  9.326ms (1798.97MB/s) | 213.892ms (  78.43MB/s) | 206.476ms (  81.25MB/s)
|run 2 | 4.255ms (3942.94MB/s) |  4.249ms (3948.51MB/s) |  4.257ms (3941.09MB/s) |  4.298ms (3903.49MB/s) | 208.269ms (  80.55MB/s) | 200.627ms (  83.62MB/s)

私の観察は次のとおりです。

  1. 1回目から2回目の実行まで、mmap'edからmalloc'edへのmemcpyは、コンテンツがすでにどこかにキャッシュされている可能性があるという利点があるようです。

  2. 64GB を超えるとパフォーマンスが大幅に低下します。これは、memcpy を使用している場合でも確認できます。

なぜそうなのかを理解したいと思います。おそらく、Linux カーネル開発者グループの誰かが考えました: 64GB は誰にとっても十分なはずです (これはベルを鳴らしますか?)

よろしく、ピーター

4

2 に答える 2

2

SuperMicro からのフィードバックに基づくと、パフォーマンスの低下は NUMA、不均一なメモリ アクセスによるものです。SuperMicro 1026GT-TF-FM109 は、中心部に 1 つの Intel 5520 Tylersburg チップセットを搭載した X8DTG-DF マザーボードを使用し、2 つの Intel Xeon E5620 CPU に接続され、それぞれに 96GB RAM が接続されています。

アプリケーションを CPU0 にロックすると、どのメモリ領域が予約され、その結果 mmap されたかに応じて、さまざまな memcpy 速度を観察できます。予約されたメモリ領域が CPU 以外の場合、mmap はしばらくの間その作業を行うのに苦労し、「リモート」領域との間の後続の memcpy はより多くの時間を消費します (データ ブロック サイズ = 16MB):

resmem=64G$4G   (inside CPU0 realm):   3949MB/s  
resmem=64G$96G  (outside CPU0 realm):    82MB/s  
resmem=64G$128G (outside CPU0 realm):  3948MB/s
resmem=92G$4G   (inside CPU0 realm):   3966MB/s            
resmem=92G$100G (outside CPU0 realm):    57MB/s

それはほとんど理にかなっています。3 番目のケースである 64G$128 のみです。これは、最上位の 64GB も良い結果をもたらすことを意味します。これはどういうわけか理論と矛盾します。

よろしく、ピーター

于 2012-04-24T14:48:17.667 に答える