プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

repeat after me このエントリーをはてなブックマークに追加

インテルの性能部隊が最近のカーネルで性能が落ちたと報告すんげー長いスレッドが始まる。
exim がlibdbつかってて、それがCPU数取得する必要があって、それが/proc/stat読むから
遅いとかいう話に。

で、Andi が fork/exec しまくったら、それぞれのプロセスが変数初期化しないと
いけないのはしょうがないんじゃ・・的な事を口走った瞬間に Linus にフルボッコに
されたでござる。



From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 15 Jun 2011 17:16:57 -0700
Message-ID: <BANLkTi=Tw6je7zpi4L=pE0JJpZfeEC9Jsg@mail.gmail.com>
Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock
to mutex


On Wed, Jun 15, 2011 at 3:19 PM, Andi Kleen wrote:
> >
> > Caching doesn't help because the library gets reinitialized in every child
> > (it may already do caching, not fully sure for this; it does it for other
> > sysconfs at least)
Why the hell do you continue to make excuses for glibc that are
*clearly*not*true*?

Stop this insanity, Andi. Do you realize that this kind of crazy
behavior just makes me convinced that there is no way in hell I should
*ever* take your sysconfig patch, since all your analysis for it is
totally worthless?

JUST LOOK AT THE NUMBERS, for chrissake!

When format_decode is 7% of the whole workload, and the top 15
functions of the profile look like this:

6.40% exim [kernel.kallsyms] [k] format_decode
5.26% exim [kernel.kallsyms] [k] page_fault
5.05% exim [kernel.kallsyms] [k] vsnprintf
3.55% exim [kernel.kallsyms] [k] number
3.00% exim [kernel.kallsyms] [k] copy_page_c
2.88% exim [kernel.kallsyms] [k] read_hpet
2.38% exim libc-2.13.90.so [.] __GI_vfprintf
1.92% exim [kernel.kallsyms] [k] kstat_irqs
1.53% exim [kernel.kallsyms] [k] find_vma
1.47% exim [kernel.kallsyms] [k] _raw_spin_lock
1.40% exim [kernel.kallsyms] [k] seq_printf
1.34% exim [kernel.kallsyms] [k] radix_tree_lookup
1.21% exim [kernel.kallsyms] [k]
page_cache_get_speculative
1.20% exim [kernel.kallsyms] [k] clear_page_c
1.05% exim [kernel.kallsyms] [k] do_page_fault

I can pretty much guarantee that it doesn't do just one /proc/stat
read per fork() just to get the number of CPU's.

/proc/stat may be slow, but it's not slower than doing real work -
unless you call it millions of times.

And you didn't actually look at glibc sources, did you? Because if you
had, you would ALSO have seen that you are totally full of sh*t. Glibc
at no point caches anything.

So repeat after me: stop making excuses and lying about glibc. It's
crap. End of story.


> > I don't think glibc is crazy in this. It has no other choice.
Stop this insanity, Andi. Why do you lie or just make up arguments? WHY?

There is very clearly no caching going on. And since exim doesn't even
execve, it just forks, it's very clear that it could cache things just
ONCE, so your argument that caching wouldn't be possible at that level
is also bogus.

I can certainly agree that /proc/stat isn't wonderful (it used to be
better), but that's no excuse for just totally making up excuses for
just plain bad *stupid* behavior in user space. And it certainly
doesn't excuse just making shit up!

Linus



リピート・アフタ・ミー!!


PS. ところで repeat after me って日本語でなんていうんだっけ、意味は分かるけど
訳せないという、このもんにょり感。なんとドンピシャが熟語があったはずなんだけど・・・
日本語難しいよ日本語


PS2 glibcのソース的には以下だね。たしかにキャッシュしてない


int
__get_nprocs ()
{
/* XXX Here will come a test for the new system call. */

const size_t buffer_size = __libc_use_alloca (8192) ? 8192 : 512;
char *buffer = alloca (buffer_size);
char *buffer_end = buffer + buffer_size;
char *cp = buffer_end;
char *re = buffer_end;
int result = 1;

#ifdef O_CLOEXEC
const int flags = O_RDONLY | O_CLOEXEC;
#else
const int flags = O_RDONLY;
#endif
/* The /proc/stat format is more uniform, use it by default. */
int fd = open_not_cancel_2 ("/proc/stat", flags);
if (fd != -1)
{
result = 0;

char *l;
while ((l = next_line (fd, buffer, &cp, &re, buffer_end)) != NULL)
/* The current format of /proc/stat has all the cpu* entries
at the front. We assume here that stays this way. */
if (strncmp (l, "cpu", 3) != 0)
break;
else if (isdigit (l[3]))
++result;

close_not_cancel_no_status (fd);
}
else
(snip)


関連記事


linux | 【2011-06-16(Thu) 10:08:50】 | Trackback:(0) | Comments:(3)
コメント
日本語だと「復唱!」ですかね。
2011-06-15 水 20:57:14 | URL | moriwaka #- [ 編集]

子供向け歌番組のノリで「さあ、ご一緒にっ!」 ぐらいのニュアンスかなーとか思いました
2011-06-15 水 23:40:31 | URL | kosaki #- [ 編集]

「ご唱和ください」すかね。
2015-07-30 木 09:23:23 | URL | てつ #- [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。