プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

そろそろkosakiについて一言いっとくか このエントリーをはてなブックマークに追加

たまに筆者が kosaki とか書いてあるけど、アレ名前じゃないから
ポーランドの地名らしいよ → http://en.wikipedia.org/wiki/Kosaki


これで誤解が1つ減ったな

関連記事
スポンサーサイト
雑談 | 【2010-04-26(Mon) 01:39:44】 | Trackback:(0) | Comments:(2)

あーなんというか このエントリーをはてなブックマークに追加

ここが匿名ぐだぐだ日記Blogということを忘れている人が多い気がする。

ななしさんなんだってば


関連記事
雑談 | 【2010-04-26(Mon) 00:47:10】 | Trackback:(0) | Comments:(0)

ハチクロはUnicodeの歴史を変えてしまったらしい このエントリーをはてなブックマークに追加

togetterで「ISO/IEC JTC 1/SC 2/WG 2 ad hoc meetings: Emojiに関するTweets」がまとめられているようだ。
すばらしい。 → http://togetter.com/li/15979http://togetter.com/li/16108

一番面白かったのは「勝ち誇り」フェイス変更のくだりで

この頭の左側のような「はぁ?なにこの鼻提灯」といった図面から


以下のような正しい鼻息に変更されたのだが
uni鼻息

そのときに使われた、日本のマンガ文化の文脈で「勝ち誇り」がどのように抽象化されているのか
という説明に使われたのが以下のコマだという






小形さんの多大なる貢献に経緯を表しつつ。そして同時に、森田先輩あなたって人は・・・・


関連記事
文字コード | 【2010-04-26(Mon) 00:34:08】 | Trackback:(0) | Comments:(1)

XFS on x86_64 このエントリーをはてなブックマークに追加

XFS on x86_64はまったく実用的ではないとかなんとかいう議論をLKMLでしている。XFSって1ページ
書き出すだけでもスタック3.5Kも使うのよね。カーネルスタックはページサイズx2なので8Kしかない。
よって


なんか色々処理
+- kmalloc
+- メモリ不足なので回収
+- pageout
+- writepage
+ kmalloc
+- このへんでさらに割り込み


とか考えるとあきらかに突き破っていて、LVMやMDやNFSを使うとそんな複雑なパターンを
考えなくても正常系で普通に突き破るという。David Chinnerが既知の問題で直せないと
言っているからには、本当にダメなんだろう。

世間の人がどうやって回避しているのか知りたいものである。

関連記事
linux | 【2010-04-25(Sun) 01:52:11】 | Trackback:(0) | Comments:(5)

CFSのnice値について このエントリーをはてなブックマークに追加

某所で話題に上がったので軽くまとめてみる
以下のようなテストプログラムを走らせてみる。nice値5とnice値10のスレッドが
ビジーループを何回回すことができるか競争するというプログラムである


struct thread_param {
int prio;
long counter;
};

#define barrier() __asm__ __volatile__("": : :"memory")

void* loop(void* _param)
{
struct thread_param *param = _param;

setpriority(PRIO_PROCESS, 0, param->prio);
usleep(1000);

for(;;) {
param->counter++;
barrier();
}

return NULL;
}

int main()
{
pthread_t thr;
cpu_set_t cpuset;
struct thread_param param1 = {
.prio = 5,
};
struct thread_param param2 = {
.prio = 10,
};

CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);

sched_setaffinity(0, sizeof(cpu_set_t), &cpuset);

pthread_create(&thr, NULL, loop, ¶m1);
pthread_create(&thr, NULL, loop, ¶m2);

sleep(1);

printf("%ld %ld %f\n", param1.counter, param2.counter,
((double)param1.counter)/param2.counter);

return 0;
}


そうすると、ほぼブレなく、のように、2つのループの差が3倍となる。
219989975 72166990 3.048346

これは kernel watchのスケジューラ特集の回 で説明したように、カーネル内部で優先度1違う毎に1.25倍のボーナスがついているので、1.25^5 ≒ 3 という理屈である。

まとめるとnice値が5変わるごとに3倍CPU時間が変わる。という関係は憶えておくと便利だよ。と

関連記事
linux | 【2010-04-25(Sun) 01:18:18】 | Trackback:(0) | Comments:(0)

kernel watch 3月号 このエントリーをはてなブックマークに追加

公開されました!

http://www.atmarkit.co.jp/flinux/rensai/watch2010/watch03a.html

今回は話の流れ上、途中でギャグをいれる余地がなかったのであるが、あの議論はこういう
レスをつけた人がいて面白かった。


お前らさっきから「古いOS」だとか「古いパーティションフォーマット」とか連呼してるけど
いいかげんにしろ!
Amiga OSとAmiga Particaionは相当古いけど2TB問題なんて存在しない。「太古の」とか
「化石の」とか「腐った」とか、もっと適切な表現で議論していただきたい!






関連記事
linux | 【2010-04-07(Wed) 16:10:55】 | Trackback:(1) | Comments:(3)

Get a better CPU このエントリーをはてなブックマークに追加

KVMでEPTだと従来よりもTLB missのコストが上がってるからページテーブルサイズを
大きくするメリットが大きくて、だから透過的hugepageが必要で、実際に性能向上が
あって・・・とか説明してる。

で、6%なんてたいした改善じゃないというLinusに「ちがうちがう。hostは+50%以上改善していて
その影響でゲストが何も変更しないでも6%改善するって言ってるんだよ」とAndreaが
説明している


On Tue, 6 Apr 2010, Andrea Arcangeli wrote:
>
> In short I first measured the page fault improvement in host (~+50%
> faster, sure that has nothing to do with pmd_huge or the tlb miss, I
> said I mentioned it just for curiosity in fact), then measured the tlb
> miss improvement in host (a few percent faster as usual with
> hugetlbfs) then measured the boost in guest if host uses hugepages
> (with no guest kernel change at all, just the tlb miss going faster in
> guest and that boosts the guest kernel compile 6%) and then some other
> test with dd with all combinations of host/guest using hugepages or
> not, and also with dd run on bare metal with or without hugepages.

Yeah, sorry. I misread your email - I noticed that 6% improvement for
something that looked like a workload I might actually _care_ about, and
didn't track the context enough to notice that it was just for the "host
is using hugepages" case.

So I thought it was a more interesting load than it was. The
virtualization "TLB miss is expensive" load I can't find it in myself to
care about. "Get a better CPU" is my answer to that one,

Linus


意訳:いやーすまんすまん。君のメールを誤読してたよ。うん、これは興味深いね、
僕は「The virtualization "TLB miss is expensive" load」について気づいてなかった
じゃあ、これが僕の新しい返事だよ


もっとマシなCPU買え



関連記事
linux | 【2010-04-06(Tue) 11:36:01】 | Trackback:(0) | Comments:(0)

sched_getaffinity()の修正が入った このエントリーをはてなブックマークに追加

忙しくて二週間ぐらい気づいていなかったが、一ヶ月ぐらい前に直した
sched_getaffinity()の非互換対処バグがマージされたようだ。

非互換といってもカーネルがバグを入れたわけではなく、
あるディストリ(Fedora?)がカーネルをNR_CPUS=4096に変えた
にもかかわらず、glibcはABI互換のためcpuset_tがNR_CPUSが
1024(or それ以下)だと決めうったコードから変えられないので、
結果として引数矛盾で常にEINVALがかえってしまっていた。

ところが、笑えることに世界唯一の4096CPUを持っているSGIは
SUSEを使っていて、SUSEは独自パッチをglibcにあてて、glibc側の
cpuset_tを4096bitに拡張しているので被害0.
被害にあっているのは小さいマシンを使っている
しもじものユーザーだという。

あまりにも馬鹿らしいのでsched_getaffinity()のABIを変えてしまった。
いままでコンパイル時に決まる最大値(=NR_CPUS)を元に引数チェックを
していたのをマシンブート時に決まる「そのマシンでの」最大CPUで
チェックするようにした。これで、CPU数が1024以下ならNR_CPUSに関係
なくちゃんと動作する。
CPUを1024個以上つんだマシンをもっている人がSUSE以外のディストリを
使っていた場合は非互換になるのだけれども、そんなユーザは事前調査で
いないことが分かっているのでさくっと無視するという対処をした
(せつこ、それ対処ちゃう)

パッチは以下のような感じの超小さいFixなのだが、ここで注目すべきは
UlrichがAckしている所である。たぶんあのキャラを知らない人には
イメージわかないと思うが、Ulrichが
1) わざわざLKMLまで出向いてきた
2) 自分が作ったわけじゃないパッチにパッチにAckしてる
という二重の意味で本当に本当にレアなパッチになっている。

もっとも、このレアさ加減はglibcにパッチを投げたことある人に
しか通じないと思うので誰とも共有できない喜びなのであるが

PS 誰かUlrichにcpu hotplugの動きを説明してやれよ。あいつが
全然理解してないから説明が面倒なことこの上ない



Reported-by: Sharyathi Nagesh
Signed-off-by: KOSAKI Motohiro
Acked-by: Ulrich Drepper
Acked-by: Peter Zijlstra
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Jack Steiner
Cc: Russ Anderson
Cc: Mike Travis
LKML-Reference: <20100312161316.9520.A69D9226@jp.fujitsu.com>
Signed-off-by: Ingo Molnar

diff --git a/kernel/sched.c b/kernel/sched.c
index 9ab3cd7..6eaef3d 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4902,7 +4902,9 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len,
int ret;
cpumask_var_t mask;

- if (len < cpumask_size())
+ if (len < nr_cpu_ids)
+ return -EINVAL;
+ if (len & (sizeof(unsigned long)-1))
return -EINVAL;

if (!alloc_cpumask_var(&mask, GFP_KERNEL))
@@ -4910,10 +4912,12 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len,

ret = sched_getaffinity(pid, mask);
if (ret == 0) {
- if (copy_to_user(user_mask_ptr, mask, cpumask_size()))
+ int retlen = min(len, cpumask_size());
+
+ if (copy_to_user(user_mask_ptr, mask, retlen))
ret = -EFAULT;
else
- ret = cpumask_size();
+ ret = retlen;
}
free_cpumask_var(mask);



関連記事
linux | 【2010-04-05(Mon) 02:03:03】 | Trackback:(0) | Comments:(0)

[kernel watch没ネタ集] secure_bzero このエントリーをはてなブックマークに追加

暗号処理関係とかはセキュリティ上の理由でkfreeの直前に0クリアしてることがよくあるけど、
最適化で0クリアが消えない保証がないので、絶対最適化で消えないゼロクリアを作ろう。
という提案。

ちなみに、Windowsは本当に消えるゼロクリアで脆弱性つくったことあったりする
secure_bzero()って名前がださい。とか変な方向に議論がながれて発散、入らなかった。

アイィィィィィィィム、セキュアーーーーー!!!!


とか叫んでればマージされたかもしれないのに。



From: Roel Kluin
To: "David S. Miller" ,
Mikael Pettersson ,
penberg@cs.helsinki.fi,
Brian Gerst ,
andi@firstfloor.org,
Andrew Morton ,
LKML ,
linux-crypto@vger.kernel.org,
Herbert@gondor.apana.org.au
Subject: [PATCH v1] compiler: prevent dead store elimination

Due to optimization A call to memset() may be removed as a dead store when
the buffer is not used after its value is overwritten. The new function
secure_bzero() ensures a section of memory is padded with zeroes.

From the GCC manual, section 5.37:
If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.

Every byte in the [p,p+n[ range must be used. If you only use the
first byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
_will_ skip scrubbing bytes beyond the first. This works with
gcc-3.2.3 up to gcc-4.4.3.

Signed-off-by: Roel Kluin
---
include/linux/compiler-gcc.h | 11 +++++++++++
include/linux/compiler-intel.h | 2 ++
include/linux/string.h | 1 +
lib/string.c | 13 +++++++++++++
4 files changed, 27 insertions(+), 0 deletions(-)

Thanks all for the required information, checkpatch.pl and compile
tested. In my (non-kernel) testcase this prevents dead store elimination.
Comments?

Roel

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 73dcf80..0799938 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -12,6 +12,17 @@
#define barrier() __asm__ __volatile__("": : :"memory")

/*
+ * Dead store elimination (DSE) is an optimization that may remove a write to
+ * a buffer that is not used anymore. Use ARRAY_PREVENT_DSE after a write when
+ * the scrub is required for security reasons.
+ */
+#define ARRAY_PREVENT_DSE(p, n) \
+ do { \
+ struct __scrub { char c[n]; }; \
+ asm("" : : "m"(*(struct __scrub *)p)); \
+ } while (0)
+
+/*
* This macro obfuscates arithmetic on a variable address so that gcc
* shouldn't recognize the original var, and make assumptions about it.
*
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index d8e636e..e8e11f3 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -14,9 +14,11 @@
* It uses intrinsics to do the equivalent things.
*/
#undef barrier
+#undef ARRAY_PREVENT_DSE
#undef RELOC_HIDE

#define barrier() __memory_barrier()
+#define ARRAY_PREVENT_DSE(p, n)

#define RELOC_HIDE(ptr, off) \
({ unsigned long __ptr; \
diff --git a/include/linux/string.h b/include/linux/string.h
index a716ee2..36213e6 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -118,6 +118,7 @@ extern void * memchr(const void *,int,__kernel_size_t);
extern char *kstrdup(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
+extern void secure_bzero(void *, __kernel_size_t);

extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
extern void argv_free(char **argv);
diff --git a/lib/string.c b/lib/string.c
index a1cdcfc..588ac31 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -559,6 +559,19 @@ void *memset(void *s, int c, size_t count)
EXPORT_SYMBOL(memset);
#endif

+/**
+ * secure_bzero - Call memset to fill a region of memory with zeroes and
+ * ensure this memset is not removed due to dead store elimination.
+ * @p: Pointer to the start of the area.
+ * @n: The size of the area.
+ */
+void secure_bzero(void *p, size_t n)
+{
+ memset(p, 0, n);
+ ARRAY_PREVENT_DSE(p, n);
+}
+EXPORT_SYMBOL(secure_bzero);
+
#ifndef __HAVE_ARCH_MEMCPY
/**
* memcpy - Copy one area of memory to another

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


関連記事
linux | 【2010-04-02(Fri) 15:26:27】 | Trackback:(0) | Comments:(0)

Rubyの1.9への移行プラン このエントリーをはてなブックマークに追加

http://www.atdot.net/~ko1/diary/201004.html#d1 から

こんなに細かく計画が決まっているOSSって滅多にない気がする


先日,ト部君と話していて 1.8 の今後のリリースプランについて聞いてきました.2011年までの 1.9 への移行のために,とても大胆な変更を行っていくそうです.

* 2010 年 7月5日 - 全ての実行をレターボックス実行に変更
* 2010 年 7月24日正午 - 珠洲市と能登町の一部(計約7,000世帯)に対してリハーサルとして 1.8 を全国に先駆けて1年早く終了する予定
* 2011 年 1月10日 - 告知メッセージを起動するたびに表示.1.9 への移行告知をさらに強化.
* 2011 年 7月1日 - 1.8 終了を知らせるメッセージと4分の1未満の枠で実行結果を表示,通常実行の出力の上に 1.8 終了を知らせる文面を前面に表示,1.8 の終了を知らせるミニ実行を繰り返し実行,1.8 終了を知らせるメッセージのみ出力のいずれかに変更.可能な場合は同年4月から前倒して実施し,順次時間を拡大させることも検討する.混乱を防止するため、2008年6月までに国とディストリビュータ事業者とで免許切れ直前に完全移行する事が決められた.
* 2011 年 7月24日 - 1.8 の終了(期限)予定日.修了の時間については混乱を避けコールセンターへの問い合わせに対応できるようにするため,同日正午とすることが2009年4月 23日に総務省内での会議で決められた.ただし技術的に困難な場合はディストリビュータ事業者個々の判断で同日24時00分まで終了を延長出来るので,予定通り終了されてもその時刻は多少バラ付きが発生する可能性がある.

いやー,本当にこんなことしていいんですかね.まだまだ 1.8 を使ってる人はいると思うんですが.




追記: どうやら誤読で、Rubyとは関係ない1.9の話だったようです。すいません


関連記事
ruby | 【2010-04-01(Thu) 23:48:31】 | Trackback:(0) | Comments:(2)

[LKML名言集] お前の雇い主は興味ないかも知れないがな! このエントリーをはてなブックマークに追加

kernel watch没ネタ集投下のお時間ですよ。

Ingoが「QEMUとか汚すぎるから、QEMUをforkしてKVMのユーザランドをLKMLで開発しよーぜー」とか言い出して
KVM関係者に「出来るわけないだろ。QEMUレベルにするのがどれだけ大変だと思ってるんだ」とフルボッコにされている。

IngoさんはWindowやMacのようなシームレスなdesktop-on-desktopがLinuxでもやりたいらしい。


I think we agree at last. Neither I nor my employer are interested in
running qemu as a desktop-on-desktop tool, therefore I don't invest any
effort in that direction, or require it from volunteers.



Avi: うん、わたしも私の雇い主もqemuをdesktop-on-desktopとして使う事に興味がないんだ。

Obviously your employer at least in part defers to you when it comes to KVM
priorities.

So, just to make this really clear, _you_ are not interested in running qemu
as a desktop-on-desktop tool, subsequently this kind of
disinterest-for-desktop-usability trickled through the whole KVM stack and
poisoned your attitude and your contributor's attitude.

Too sad really and it's doubly sad that you dont feel anything wrong about
that.



Ingo: ああ、君の雇い主はそうだろうよ。オレは悲しいぜ、君もそう思っているなんて



この議論のポイントは二人は同じ会社に勤めているということである



関連記事
linux | 【2010-04-01(Thu) 10:25:27】 | Trackback:(0) | Comments:(0)

[LKML名言集] Don't be linus このエントリーをはてなブックマークに追加

/porc/{pid}/pagemap が大嫌いなLinusがpagemapへのバグ報告を機に、
このインターフェースをまるごと削除しようぜーとか騒いでいる。

I would seriously suggest that we consider removing the 'pagemap'
interface. The way that code looks, it's just broken.



意訳:おれは本気でpagemapを削除することを提案するね。あれは完全に壊れてるよ

それに対する、pagemap作者mattの返事

Linus, I must say your charm has really worn thin. I've just stuck a
post-it on my monitor saying "don't be Linus" to remind me not to be
rude to my contributors.



意訳:Linus、おれはモニターに「don't be Linus」と書いてあるポストイットを貼ってるよ。
コントリビュータに無礼な態度をとらないことを忘れないようにね。


発言は笑えるが、ギャグをかましているヒマがあったらバグを直せよ

関連記事
linux | 【2010-04-01(Thu) 09:48:17】 | Trackback:(0) | Comments:(0)

Rubyのコミッターになりました このエントリーをはてなブックマークに追加

4月1日ですね。

このたびめでたくRubyのコミッターに就任しました

shinh先生のこんにちわ世界が理解できなかった僕は間違いなくnariさんの
「Rubyをもっとも知らないコミッタです」の称号を奪う権利があると思います。
nariさんblog書き換えてください(キリッ

そういうわけで、今年はLinuxにあわせてRubyもがんばっていきたいと思います。
まずはまっとうな、世界にこんにちわプログラムから憶えていきます!

ではでは


関連記事
ruby | 【2010-04-01(Thu) 01:51:03】 | Trackback:(0) | Comments:(1)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。