November 2007

おうちを無線LANにしたせいで、Linux環境がピンチなのであった
このエントリーをはてなブックマークに追加

今日もページ回収処理を黙々と読む
このエントリーをはてなブックマークに追加

blogに数式を書くときってみんなどうしてるの?
いきなり挫折したんだが(´・ω・`)
このエントリーをはてなブックマークに追加

PF_MEMDIEのあつかいがRHEL4とRHEL5でかなり違っていることに気づいたのでメモ

まずRHEL4(kernel2.6.9ベース)

フラグが立つのは以下。
つまり、OOM killで死ぬ事が決定したタスクに立つ
static void __oom_kill_task(task_t *p)
{
(略)
p->time_slice = HZ;
p->flags |= PF_MEMALLOC | PF_MEMDIE; // ★

/* This process has hardware access, be more careful. */
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}



んで、使っているところその①
OOM killだと殺すのにSIGKILL使っているので、KILL送っても即死するとは限らない
んで、死刑確定プロセスに何回も死刑宣告しても意味がないし、
そもそも、死体に死刑宣告してメモリ空いた気になって次の処理に進んでも有害無益なので
OOM kill対象に選ばれるべきではない
static unsigned long badness(struct task_struct *p, unsigned long uptime)
{
unsigned long points, cpu_time, run_time, s;

if (!p->mm)
return 0;

if (p->flags & PF_MEMDIE) //★ここ
return 0;


使っているところその②
OOM killする処理の途中でメモリ不足でタスクが寝てしまって処理が進まなくなると
いつまでたってもメモリが空かないのでよろしくない。
よって、メモリ確保ルーチンでボーナスを与えている

struct page * fastcall
__alloc_pages(unsigned int gfp_mask, unsigned int order,
struct zonelist *zonelist)
{
  (略)
/* This allocation should allow future memory freeing. */
if ((p->flags & (PF_MEMALLOC | PF_MEMDIE)) && !in_interrupt()) { //★ここ
/* go through the zonelist yet again, ignoring mins */
for (i = 0; (z = zones[i]) != NULL; i++) {
page = buffered_rmqueue(z, order, gfp_mask);
if (page)
goto got_pg;
}
goto nopage;
}


audit関係は興味がないので、割愛


次にRHEL5(kernel2.6.18ベース)

まず、フラグの名前からして違う
PF_MEMDIEはTIF_MEMDIEに変わっており、かつtask_structのフラグからthread_infoのフラグに
変更されている。
(ぶっちゃけ、引っ越した理由が理解できず・・・)

フラグが立つのは以下。
同じく、OOM killで死ぬ事が決定したタスクに立つ
static void __oom_kill_task(struct task_struct *p, const char *message)
{
(略)
/*
* We give our sacrificial lamb high priority and access to
* all the memory it needs. That way it should be able to
* exit() and clear out its resources quickly...
*/
p->time_slice = HZ;
set_tsk_thread_flag(p, TIF_MEMDIE); //★ここ

force_sig(SIGKILL, p);
}



フラグを見ている場所その①
まず目立つのは、基本的にループ回ってる最中に1つでもTIF_MEMDIEを見つけたら
いきなり関数抜けてOOM kill処理をスキップしちゃうこと。
これで、メモリ不足時に
1.システムがスローダウンしていて、なかなかOOM killが終わらない(メモリが空かない)
2.次々とプロセスがOOM kill対象になり、SIGKILLを送られまくる
3.大量虐殺
というコンボを防いでいる

PF_DEADはtask_struct以外は全部解放終わり、あと1回schedule()されたら死ぬよん
という、ホンマに死ぬ直前なので、恩赦対象

PF_EXITINGはexit()やsignalで死に始めてからPF_DEADになるまでの終了途中状態。
なんだけども、なんでこの時にbreakしてるのかが意味が分からん。
ここはtaskとthreadの2重ループなので、breakしても自タスク内スレッドループ抜けるだけで
処理は続くが、*ppointsはULONG_MAX入れてるので、これ以上のポイントを持つタスクが
見つかるはずもない。
大体、PF_EXITINGまで行ったやつにもう一度SIGKILL送っても無視されるだけだと思うので
そんなヤツ選択してなんか意味あるかぁ??

明日また考えよう ← 絶対やらない
static struct task_struct *select_bad_process(unsigned long *ppoints)
{
(略)
releasing = test_tsk_thread_flag(p, TIF_MEMDIE) || //★ここ
p->flags & PF_EXITING;
if (releasing) {
/* PF_DEAD tasks have already released their mm */
if (p->flags & PF_DEAD)
continue;
if (p->flags & PF_EXITING && p == current) {
chosen = p; //★ 自殺
*ppoints = ULONG_MAX;
break;
}
return ERR_PTR(-1UL); //★ OOM killしない
}


フラグを見ている場所その②
主にCPU1個のマシン対策。out of memory発生し自分が死亡対象じゃない
(=どこか別プロセスが死刑宣告された)
というときは、sigkillの動作的に一旦死亡対象プロセスがスケジューリングされないと
死に終わらない。
なので、ちょっとだけ寝てあげるとこの関数を抜けるまでに死に終わっている確率が上がり
無駄に再度のOOMを発生させてしまう事を防いでいる
void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, int order)
{
(略)
/*
* Give "p" a good chance of killing itself before we
* retry to allocate memory unless "p" is current
*/
if (!test_thread_flag(TIF_MEMDIE))
schedule_timeout_uninterruptible(1);
}



使っている場所その③
RHEL4とおなじく、メモリ確保時のボーナス

struct page * fastcall
__alloc_pages(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist)
{
  (略)
/* This allocation should allow future memory freeing. */

if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
&& !in_interrupt()) {
if (!(gfp_mask & __GFP_NOMEMALLOC)) {
nofail_alloc:
/* go through the zonelist yet again, ignoring mins */
page = get_page_from_freelist(gfp_mask, order,
zonelist, ALLOC_NO_WATERMARKS);
if (page)
goto got_pg;
if (gfp_mask & __GFP_NOFAIL) {
blk_congestion_wait(WRITE, HZ/50);
goto nofail_alloc;
}
}
goto nopage;
}



追記: このへん(http://www.ussg.iu.edu/hypermail/linux/kernel/0501.2/1542.html)にPF_MEMDIEがTIF_MEMDIEになった経緯が書いてあった。
ようするにtask_struct.flagsはふつうのulongでatomic操作できないんだから、自タスク以外が操作するフラグはTIF_XXにしないとダメってこと。

追記2: このへん(http://www.ussg.iu.edu/hypermail/linux/kernel/0501.2/1541.html)をみると、TIF_MEMDIEが見つかったらスキップしてるのは5秒ウェイトの変わりみたい。
なるほど、5秒じゃメモリ解放が終わらないときはどーすんねん。と
このエントリーをはてなブックマークに追加

手近におもちゃに出来るLinux Boxがなかったので、VMware上でカーネルコンパイルしてたんだが、うっかり make -j 20とかやってえらい目にあった(^^;

やっぱ仮想マシンはメモリ競合させるととんでもないCPU使用率になって、ホストOSの操作すら出来なくなるので辛いのう
このエントリーをはてなブックマークに追加

http://alohakun.blog7.fc2.com/blog-entry-877.htmlより

僕も kosaki さんのように,twitter を止めて FC2 blog に一行日記を何のためらいも無く書けるような剛毅さを身に着けないとな,とかなんとか.

はてなの人は,一日に何度も一行日記を気軽に更新できて良いなとは思う.FC2 は一応ブログですからね.それなりの分量の文章を書かないと,格好が付かない感じがします.



blogとはてなって一緒だと思ってました・・・
見なかったフリ
このエントリーをはてなブックマークに追加

http://d.hatena.ne.jp/nminoru/20071118/nasa より

【ワシントン和田浩明】「激突すれば被害は甚大。対応を強化すべきだ」「予算の制約上、体制拡大は困難」--。米下院で今月、地球に衝突する可能性がある小惑星を発見・監視する米航空宇宙局(NASA)のプログラムに関する公聴会が開催され、議員とNASAの間でこんな議論が交わされた。

米議会は05年、太陽から約2億キロ以内にある、直径140メートル以上の物体の9割を15年以内に発見・監視する計画の提出をNASAに求めた。

しかし下院科学委員会の宇宙航空小委員会で証言したNASA幹部は、現体制では議会が設定した監視対象の14%しか発見できないと説明。他国政府の観測施設を使い、新たな専用天文台を建設したうえで、監視対象の範囲を大幅に狭めれば目標達成は可能と述べた。

これに対し同小委のバート・ゴードン委員長(民主党)は「NASAの報告は不十分」として計画の練り直しを求めた。

小惑星の激突は約6500万年前の恐竜の絶滅を引き起こしたとされる。NASAによると、議会が監視を求めるサイズの小惑星は約10万個。最近では89年に小惑星が地球の70万キロ付近に接近したが、発見されたのは最接近後だった。

毎日新聞:米下院:小惑星激突対策不十分 議員がNASAつきあげ




議員さんも無茶言いますなぁ。人工衛星の残骸すら管理し切れていないのに、小惑星まで監視しろって無理ですよ。




むしろ、この議員が最近みた映画を当てるゲームに発展させたほうが盛り上がるんじゃね?
このエントリーをはてなブックマークに追加

http://www.chikawatanabe.com/blog/2007/11/jtpa.html より

NPOのJTPAが行う毎年恒例シリコンバレーツアー。参加者限定20名で、日本から若手を招き、三日間、シリコンバレーの会社見学、シリコンバレーで働く日本人による息苦しいまでのパネルディスカッション、スタンフォード大学訪問などを行います。シリコンバレーで働いてみたい方が対象。

12月に応募要綱を発表しますが、それまでの間、告知バナー(バッジ)をサイトに貼って告知に協力してくださる方大募集。




趣旨に賛同するときは広告でも応援を厭いません事よ。おほほ
みんなガンガレ!


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

みんな仕事はやいよ。
とりあえず、引用しとく


We are pleased to announce the 10th Anniversary Linux Symposium will be
held from July 23 ~ 26, 2008 in Ottawa, Canada. The Symposium will also
feature multiple keynote presentations, in depth tutorials, birds of a
feather sessions, papers on the most current topics in Linux and Open
Source, mini summits open to related Linux and Open Source projects to be
held in the day(s) before the Symposium and speakers from outside the
industry who will share their experiences with Linux and Open Source and
its impact.

Call For Papers
The CFP for 2008 offers a lot of opportunities for submissions on a wide
range of topics that are of interest to the Linux and Open Source
community. We strongly encourage you to submit proposals on the topics
listed as well as any subject that you feel would be an interesting and
informative addition to the schedule. You can view the CFP online at
http://www.linuxsymposium.org/2008/cfp.php.

Mini Summits
We will also be accepting submissions for mini summits. These will be held
on the day(s) before the Linux Symposium, with venue and any technical
requirements (i.e. projector, screen, etc.) provided by Linux Symposium
and our sponsors. Mini summit proposals can be submitted via email to
info@linuxsymposium.org (online submission will be available soon). Please
include the following information: topic, moderator, expected time required
(1/2 day, 1 day, 2 days), number of attendees, technical requirements and
any other relevant information. Make sure that you submit your mini
summit proposal early as space is limited.

Registration
You can register for the 2008 Linux Symposium at
http://www.linuxsymposium.org/ by logging in using your account or by
registering online. Registration rates are as follows:

Before April 1st, 2008
General - $350.00
Student - $200.00

Before June 1st, 2008
General ~ $500.00
Student ~ $250.00

After June 1st, 2008
General ~ $750.00
Student ~ $275.00

For all other information and announcements, please visit us online at
http://www.linuxsymposium.org/.

We look forward to receiving your proposals and seeing you all in July!

Thank you,

Linux Symposium Organizers


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

↑このページのトップヘ