Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 15765] ファイルの概要

このコミットは、GoランタイムにおけるLinux向けネットワークポーラーの統合に関するものです。既存のネットワークI/O処理メカニズムを、Linuxカーネルが提供する高性能なepollシステムコールを直接利用するように変更し、Goランタイムのスケジューラとより密接に連携させることで、ネットワークパフォーマンスの大幅な向上を図っています。特に、多数の同時接続を扱うアプリケーションにおいて、I/Oの効率化とレイテンシの削減に貢献します。

コミット

commit 49e0300854dabc8d3c2e91d26897a998345f2447
Author: Dmitriy Vyukov <dvyukov@google.com>
Date:   Thu Mar 14 19:06:35 2013 +0400

    runtime: integrated network poller for linux
    vs tip:
    BenchmarkTCP4OneShot                    172994        40485  -76.60%
    BenchmarkTCP4OneShot-2                   96581        30028  -68.91%
    BenchmarkTCP4OneShot-4                   52615        18454  -64.93%
    BenchmarkTCP4OneShot-8                   26351        12289  -53.36%
    BenchmarkTCP4OneShot-16                  12258        16093  +31.29%
    BenchmarkTCP4OneShot-32                  13200        17045  +29.13%
    
    BenchmarkTCP4OneShotTimeout             124814        42932  -65.60%
    BenchmarkTCP4OneShotTimeout-2            99090        29040  -70.69%
    BenchmarkTCP4OneShotTimeout-4            51860        18455  -64.41%
    BenchmarkTCP4OneShotTimeout-8            26100        12073  -53.74%
    BenchmarkTCP4OneShotTimeout-16           12198        16654  +36.53%
    BenchmarkTCP4OneShotTimeout-32           13438        17143  +27.57%
    
    BenchmarkTCP4Persistent                 115647         7782  -93.27%
    BenchmarkTCP4Persistent-2                58024         4808  -91.71%
    BenchmarkTCP4Persistent-4                24715         3674  -85.13%
    BenchmarkTCP4Persistent-8                16431         2407  -85.35%
    BenchmarkTCP4Persistent-16                2336         1875  -19.73%
    BenchmarkTCP4Persistent-32                1689         1637   -3.08%
    
    BenchmarkTCP4PersistentTimeout           79754         7859  -90.15%
    BenchmarkTCP4PersistentTimeout-2         57708         5952  -89.69%
    BenchmarkTCP4PersistentTimeout-4         26907         3823  -85.79%
    BenchmarkTCP4PersistentTimeout-8         15036         2567  -82.93%
    BenchmarkTCP4PersistentTimeout-16         2507         1903  -24.09%
    BenchmarkTCP4PersistentTimeout-32         1717         1627   -5.24%
    
    vs old scheduler:
    benchmark                           old ns/op    new ns/op    delta
    BenchmarkTCPOneShot                    192244        40485  -78.94%
    BenchmarkTCPOneShot-2                   63835        30028  -52.96%
    BenchmarkTCPOneShot-4                   35443        18454  -47.93%
    BenchmarkTCPOneShot-8                   22140        12289  -44.49%
    BenchmarkTCPOneShot-16                  16930        16093   -4.94%
    BenchmarkTCPOneShot-32                  16719        17045   +1.95%
    
    BenchmarkTCPOneShotTimeout             190495        42932  -77.46%
    BenchmarkTCPOneShotTimeout-2            64828        29040  -55.20%
    BenchmarkTCPOneShotTimeout-4            34591        18455  -46.65%
    BenchmarkTCPOneShotTimeout-8            21989        12073  -45.10%
    BenchmarkTCPOneShotTimeout-16           16848        16654   -1.15%
    BenchmarkTCPOneShotTimeout-32           16796        17143   +2.07%
    
    BenchmarkTCPPersistent                  81670         7782  -90.47%
    BenchmarkTCPPersistent-2                26598         4808  -81.92%
    BenchmarkTCPPersistent-4                15633         3674  -76.50%
    BenchmarkTCPPersistent-8                18093         2407  -86.70%
    BenchmarkTCPPersistent-16               17472         1875  -89.27%
    BenchmarkTCPPersistent-32                7679         1637  -78.68%
    
    BenchmarkTCPPersistentTimeout           83186         7859  -90.55%
    BenchmarkTCPPersistentTimeout-2         26883         5952  -77.86%
    BenchmarkTCPPersistentTimeout-4         15776         3823  -75.77%
    BenchmarkTCPPersistentTimeout-8         18180         2567  -85.88%
    BenchmarkTCPPersistentTimeout-16        17454         1903  -89.10%
    BenchmarkTCPPersistentTimeout-32         7798         1627  -79.14%
    
    R=golang-dev, iant, bradfitz, dave, rsc
    CC=golang-dev
    https://golang.org/cl/7579044

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/49e0300854dabc8d3c2e91d26897a998345f2447

元コミット内容

このコミットは、GoランタイムにLinux向けの統合されたネットワークポーラーを導入するものです。ベンチマーク結果が示唆するように、特に低〜中程度の並行性において、TCPネットワーク操作のパフォーマンスが大幅に向上しています。これは、GoのネットワークI/O処理が、より効率的なepollシステムコールを直接利用するように変更されたためです。

変更の背景

Go言語は、その並行処理モデルと軽量なゴルーチンによって、高効率なネットワークサービスを構築するのに適しています。しかし、ネットワークI/Oの効率は、基盤となるオペレーティングシステムのI/O多重化メカニズムに大きく依存します。従来のGoのネットワークポーラーは、selectやpollといったシステムコールを使用していたか、あるいはepollを間接的に利用していた可能性があります。これらのメカニズムは、多数のファイルディスクリプタ（FD）を扱う際にスケーラビリティの問題を抱えることがありました。

Linuxカーネルが提供するepollは、特に多数のFDを効率的に監視するために設計されたI/Oイベント通知メカニズムです。epollは、監視対象のFDの数が多くなっても、そのパフォーマンスがFDの総数に比例して劣化しにくいという特性を持っています。Goランタイムがepollを直接、かつより深く統合することで、ネットワークI/Oのオーバーヘッドを削減し、ゴルーチンのスケジューリングとI/Oイベントの通知をより密接に連携させることが可能になります。これにより、特に高負荷なネットワークアプリケーションにおいて、スループットの向上とレイテンシの削減が期待されます。

コミットメッセージに記載されているベンチマーク結果は、この変更がもたらすパフォーマンス上の大きなメリットを明確に示しています。特にBenchmarkTCP4Persistentのような持続的な接続を伴うシナリオでは、90%以上の性能向上が見られ、これはネットワークI/O処理の根本的な改善があったことを強く示唆しています。

前提知識の解説

1. I/O多重化 (I/O Multiplexing)

I/O多重化とは、単一のスレッドで複数のI/O操作（ネットワークソケットからの読み書き、ファイルI/Oなど）を同時に監視し、準備ができたI/O操作のみを処理する技術です。これにより、I/O待ちのためにスレッドがブロックされるのを防ぎ、システムリソースを効率的に利用できます。

  • select: 最も古いI/O多重化メカニズムの一つ。監視対象のFDのリストをカーネルに渡し、準備ができたFDを返します。FDの数が増えると、カーネルとユーザー空間間のデータコピーのオーバーヘッドが大きくなり、パフォーマンスが劣化します。
  • poll: selectと同様の機能を提供しますが、FDの数に制限がありません。しかし、FDの数が増えるとパフォーマンスが劣化するという基本的な問題はselectと共通です。
  • epoll (Linux固有): Linuxカーネル2.5.44以降で導入された、高性能なI/O多重化メカニズムです。selectやpollとは異なり、監視対象のFDをカーネル内部に登録し、イベントが発生したFDのみを通知する「イベント駆動型」のモデルを採用しています。これにより、FDの数が増えてもパフォーマンスの劣化が少なく、大規模なネットワークアプリケーションに適しています。
    • epoll_create/epoll_create1: epollインスタンスを作成します。
    • epoll_ctl: epollインスタンスにFDを追加、変更、削除します。
    • epoll_wait: イベントが発生するまでブロックし、準備ができたFDのリストを返します。

2. Goランタイムとスケジューラ

Go言語のランタイムは、ゴルーチン（軽量スレッド）のスケジューリング、メモリ管理（ガベージコレクション）、ネットワークI/Oの抽象化などを担当します。Goのスケジューラは、M:Nスケジューリングモデル（M個のゴルーチンをN個のOSスレッドにマッピング）を採用しており、I/O操作でブロックされるゴルーチンが発生した場合でも、他のゴルーチンを効率的に実行し続けることができます。

ネットワークI/Oは、通常、システムコールを介して行われます。Goのランタイムは、これらのシステムコールをラップし、I/Oが完了するまでゴルーチンをブロックする代わりに、そのゴルーチンを「待機中」の状態にし、他のゴルーチンを実行します。I/Oが完了すると、ランタイムは待機中のゴルーチンを「実行可能」状態に戻し、スケジューラがそれを再開します。このI/O処理の効率が、Goアプリケーション全体のパフォーマンスに直結します。

3. ビルドタグ (Build Tags)

Goのビルドタグは、特定の環境（OS、アーキテクチャなど）でのみコンパイルされるコードを指定するために使用されます。+buildディレクティブをソースファイルの先頭に記述することで、コンパイラは指定されたタグに合致する場合にのみそのファイルをコンパイルします。

例:

  • // +build linux,amd64: LinuxかつAMD64アーキテクチャの場合にコンパイル
  • // +build !windows: Windows以外の場合にコンパイル

このコミットでは、epollがLinux固有の機能であるため、関連するコードがLinux環境でのみコンパイルされるようにビルドタグが調整されています。

技術的詳細

このコミットの主要な技術的変更点は、GoランタイムがLinuxのepollシステムコールを直接利用するように再構築されたことです。

  1. epollシステムコールの直接利用:

    • src/pkg/runtime/sys_linux_386.s および src/pkg/runtime/sys_linux_amd64.s に、epoll_create、epoll_create1、epoll_ctl、epoll_wait といったepoll関連のシステムコールを呼び出すためのアセンブリコードが追加されました。これにより、GoランタイムはCgoを介さずに、直接カーネルのepoll機能にアクセスできるようになります。これは、Cgoのオーバーヘッドを回避し、パフォーマンスを最大化するために重要です。
    • src/pkg/runtime/defs2_linux.go および src/pkg/runtime/defs_linux.go に、epoll関連の定数（EPOLLIN, EPOLLOUT, EPOLL_CTL_ADDなど）とEpollEvent構造体の定義が追加されました。これらは、Goコードからepollシステムコールを呼び出す際に必要な引数や戻り値の型を定義します。

  2. 新しいネットワークポーラーの実装:

    • src/pkg/runtime/netpoll_epoll.c という新しいファイルが追加されました。このファイルは、Linuxのepollを基盤としたGoランタイムのネットワークポーラーのコアロジックを含んでいます。
      • runtime·netpollinit(): epollインスタンスを作成します。epoll_create1が利用可能であればそれを使用し、そうでなければepoll_createを使用します。
      • runtime·netpollopen(): 監視対象のファイルディスクリプタ（FD）をepollインスタンスに登録します。EPOLLIN, EPOLLOUT, EPOLLRDHUP, EPOLLET（エッジトリガー）などのイベントフラグを設定し、関連するPollDesc（ポーリング記述子）をepoll_dataに格納します。
      • runtime·netpoll(): epoll_waitを呼び出して、I/Oイベントが発生するまで待機します。イベントが発生すると、対応するゴルーチンをruntime·netpollready()を介して実行可能状態に戻します。これにより、I/Oが完了したゴルーチンがGoスケジューラによって速やかに再開されます。

  3. 既存のネットワークI/Oコードの削除と調整:

    • src/pkg/net/fd_linux.go が削除されました。このファイルは、以前のLinux固有のファイルディスクリプタポーリングの実装を含んでおり、新しいランタイムレベルのepollポーラーに置き換えられました。
    • src/pkg/net/fd_poll_runtime.go と src/pkg/runtime/netpoll.goc のビルドタグが更新され、Linuxの386およびamd64アーキテクチャが新しいepollポーラーを使用するように変更されました。
    • src/pkg/net/fd_poll_unix.go と src/pkg/runtime/netpoll_stub.c のビルドタグが調整され、Linuxのarmアーキテクチャや他のUnix系OSが引き続き汎用的なポーリングメカニズムを使用するように分離されました。これは、epollがLinux固有であるため、他のプラットフォームでは異なるI/O多重化メカニズムが必要となるためです。

  4. エラー定数の定義の整理:

    • src/pkg/runtime/mem_linux.c および src/pkg/runtime/thread_linux.c から、EINTR、EAGAIN、ENOMEMといったエラー定数の定義が削除されました。これらの定数は、src/pkg/runtime/defs2_linux.go および src/pkg/runtime/defs_linux.go でCgoを介してカーネルから直接インポートされるようになったため、重複が解消されました。

これらの変更により、GoのネットワークI/O処理は、Linux上でより効率的かつスケーラブルなepollベースのメカニズムに移行し、Goアプリケーションのネットワークパフォーマンスが大幅に向上しました。

コアとなるコードの変更箇所

このコミットのコアとなる変更は、主に以下のファイルに集中しています。

  1. src/pkg/net/fd_linux.go の削除:

    • 以前のLinux固有のネットワークI/Oポーリングロジックが完全に削除されました。

  2. src/pkg/runtime/netpoll_epoll.c の新規追加:

    • Linuxのepollシステムコールを直接利用する新しいネットワークポーラーのC言語実装です。
    • runtime·netpollinit(): epollインスタンスの初期化。
    • runtime·netpollopen(): FDをepollに登録。
    • runtime·netpoll(): epoll_waitを呼び出し、イベントを処理してゴルーチンを再開。

  3. src/pkg/runtime/sys_linux_386.s および src/pkg/runtime/sys_linux_amd64.s の変更:

    • epoll_create, epoll_create1, epoll_ctl, epoll_wait システムコールを呼び出すためのアセンブリルーチンが追加されました。これにより、Goランタイムが直接これらのカーネル機能にアクセスできるようになります。

  4. src/pkg/runtime/defs2_linux.go および src/pkg/runtime/defs_linux.go の変更:

    • epoll関連の定数（EPOLLIN, EPOLLOUT, EPOLL_CTL_ADDなど）とEpollEvent構造体が追加され、Goコードからepollシステムコールを扱うための型定義が整備されました。

  5. ビルドタグの変更:

    • src/pkg/net/fd_poll_runtime.go と src/pkg/runtime/netpoll.goc がLinuxの386およびamd64アーキテクチャで新しいepollポーラーを使用するように変更。
    • src/pkg/net/fd_poll_unix.go と src/pkg/runtime/netpoll_stub.c がLinuxのarmアーキテクチャや他のUnix系OS向けに調整され、epollポーラーの適用範囲が明確化されました。

コアとなるコードの解説

src/pkg/runtime/netpoll_epoll.c (抜粋)

// Copyright 2013 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build linux,386 linux,amd64

#include "runtime.h"
#include "defs_GOOS_GOARCH.h"

int32	runtime·epollcreate(int32 size);
int32	runtime·epollcreate1(int32 flags);
int32	runtime·epollctl(int32 epfd, int32 op, int32 fd, EpollEvent *ev);
int32	runtime·epollwait(int32 epfd, EpollEvent *ev, int32 nev, int32 timeout);
void	runtime·closeonexec(int32 fd);

static int32 epfd = -1;  // epoll descriptor

void
runtime·netpollinit(void)
{
	epfd = runtime·epollcreate1(EPOLL_CLOEXEC);
	if(epfd >= 0)
		return;
	epfd = runtime·epollcreate(1024);
	if(epfd >= 0) {
		runtime·closeonexec(epfd);
		return;
	}
	runtime·printf("netpollinit: failed to create descriptor (%d)\n", -epfd);
	runtime·throw("netpollinit: failed to create descriptor");
}

int32
runtime·netpollopen(int32 fd, PollDesc *pd)
{
	EpollEvent ev;

	ev.events = EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET;
	ev.data = (uint64)pd;
	return runtime·epollctl(epfd, EPOLL_CTL_ADD, fd, &ev);
}

// polls for ready network connections
// returns list of goroutines that become runnable
G*
runtime·netpoll(bool block)
{
	EpollEvent events[128], *ev;
	int32 n, i, waitms, mode;
	G *gp;

	if(epfd == -1)
		return nil;
	waitms = -1;
	if(!block)
		waitms = 0;
retry:
	n = runtime·epollwait(epfd, events, nelem(events), waitms);
	if(n < 0) {
		if(n != -EINTR)
			runtime·printf("epollwait failed with %d\n", -n);
		goto retry;
	}
	gp = nil;
	for(i = 0; i < n; i++) {
		ev = &events[i];
		if(ev->events == 0)
			continue;
		mode = 0;
		if(ev->events & (EPOLLIN|EPOLLRDHUP|EPOLLHUP|EPOLLERR))
			mode += 'r';
		if(ev->events & (EPOLLOUT|EPOLLHUP|EPOLLERR))
			mode += 'w';
		if(mode)
			runtime·netpollready(&gp, (void*)ev->data, mode);
	}
	if(block && gp == nil)
		goto retry;
	return gp;
}
  • runtime·netpollinit(): epollインスタンスを初期化します。まずepoll_create1（EPOLL_CLOEXECフラグ付きで、FDがexec時にクローズされるようにする）を試み、失敗した場合は古いepoll_createを使用します。これは、古いLinuxカーネルとの互換性を保つためです。
  • runtime·netpollopen(): ネットワークFDがオープンされる際に呼び出され、そのFDをepollインスタンスに登録します。EPOLLIN（読み込み可能）、EPOLLOUT（書き込み可能）、EPOLLRDHUP（リモートからの切断）、EPOLLET（エッジトリガーモード）などのイベントを監視対象として設定します。ev.dataには、そのFDに関連付けられたPollDesc構造体へのポインタが格納され、イベント発生時にどのゴルーチンを再開すべきかを特定するために使用されます。
  • runtime·netpoll(): Goスケジューラから定期的に呼び出される関数で、I/Oイベントをポーリングします。
    • runtime·epollwait()を呼び出し、イベントが発生するまで待機します。block引数によって、ブロックするか（waitms = -1）即座にリターンするか（waitms = 0）を制御します。
    • イベントが発生すると、events配列に格納されたEpollEvent構造体をループで処理します。
    • 各イベントについて、発生したイベントの種類（読み込み、書き込み、エラーなど）を判断し、対応するmodeを設定します。
    • runtime·netpollready()を呼び出し、ev->dataに格納されたPollDescポインタを使って、関連するゴルーチンを実行可能状態（gpリストに追加）に戻します。これにより、I/O待ちでブロックされていたゴルーチンがGoスケジューラによって再開され、処理を続行できるようになります。
    • blockモードで、かつイベントが一つもなかった場合は、再度epollwaitを呼び出してイベントを待ちます（goto retry）。

このCコードは、Goランタイムの内部で直接Linuxカーネルのepoll APIを叩くことで、GoのネットワークI/O処理の効率を最大化しています。

関連リンク

参考にした情報源リンク

  • Go言語の公式ドキュメント
  • Linuxカーネルのドキュメント
  • epollに関する技術記事や解説
  • Goのソースコード（特にsrc/pkg/runtimeおよびsrc/pkg/netディレクトリ）
  • コミットメッセージに記載されているベンチマーク結果
  • GoのIssueトラッカーやメーリングリストでの議論 (golang-dev)