>>37
> goroutineスタック分以外は全てRSSに入る前提の元
いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
そしてスワップアウトは「必要ない限りやらない」のが基本だから普通にベンチマークしてれば問題ない。
(同時にメモリイーターなプロセスを走らせておかないと速攻スワップアウトなんてされない）

> カーネルで管理されているメモリは4KB/2KBとかじゃないと思うし
『プロセス』を管理するために必要なカーネル側のメモリは4kBとかではない。
PTE(PageTableEntry=MMUの中身データ）だけでもメモリ128MBなら4k/pageだと128kB(=32kentry*4Bytes)必要になる。
（ただしラージページ《2M/page》なら256Bytesで済むが)
だから『プロセス』は軽くない。

一方、『スレッド』についてはこの部分は必要なく、追加のスレッドによって増えるカーネル側メモリは、
スレッド管理分のフラグ類の数Bytesと、待避領域の1kBだけで済むはず。
4k/threadの見積もりは多すぎ。(多分)

> Goの「スイッチングポイント」は現状誰も明示しておらず、保存しているものも、どこなのかも、推測の範疇を出ておらず、議論は無意味。
それはそうだが、多分合ってると思うよ。ただ、
> どこなのかも、
これについては間違いなくユーザー空間のはずだよ。カーネル側に保存する意味がないし、余計に遅くなる。
誤解無いようにくどいが言っておくと、
OSの管轄でマシンスレッドからプリエンプトする場合、各マシンスレッドの状態待避はカーネルがカーネル空間側に行う。
Goランタイムの管轄でgoroutineを切り替える場合、各goroutineの状態待避はGoランタイムがユーザー空間側に行う。
(まさかGoランタイムってカーネルモードで動いてたりする？それなら話は違ってくるが)