April 2009

http://cvs.m17n.org/~akr/diary/2009-04.html#a2009_04_15

このへんの資料みながら。
SUSによると、マルチスレッドプログラムはforkしたあと、async-signal-safeオペレーションしか、しちゃダメということになっている。
特に glibc とかだと、規格を守らない奴がバカ。ってスタンスなので、libc 呼び出し中にforkしたらハングしても文句はいえない。
libc の中でmutex使っていけないというルールはないから。

http://www.opengroup.org/onlinepubs/009695399/functions/fork.html

A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] [Option Start] Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. [Option End]

When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not asynch-signal-safe, the behavior is undefined.



要約:
fork時はスレッドは呼び出しスレッドしかコピーされない。でもmutexやらなんやらの状態はコピーされてしまう。必然的にexecute async-signal-safe な操作しかしちゃだめってこった。


でも、実際問題として、世の中には規格を調べない人がいっぱいいるので・・・
このエントリーをはてなブックマークに追加

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html

続く drop_caches の説明も間違ってる

0. デフォルト状態に戻す場合

# echo 0 > /proc/sys/vm/drop_caches



と書かれているが、当該箇所のソースは以下である

linux/fs/drop_caches.c

int drop_caches_sysctl_handler(ctl_table *table, int write,
struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
{
proc_dointvec_minmax(table, write, file, buffer, length, ppos);
if (write) {
if (sysctl_drop_caches & 1)
drop_pagecache();
if (sysctl_drop_caches & 2)
drop_slab();
}
return 0;
}


要するに、0なんか書き込んでも無視されているだけである。drop_cachesはいかなる状態も管理なんかしていない。
ただのキャッシュ破棄用のインターフェースにすぎない

かつ、RHELだと古いバージョンはバグがあってOSがハングする可能性があるので、安易に drop_caches を勧めるのもどうかと思う。
このエントリーをはてなブックマークに追加

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html

 Activeはページキャッシュや無名ページ(注3)のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。

(実際に利用可能なメモリ量)≒(MemFree+Inactive)

 この値を利用し、一定量を下回らないようにするのが、簡単・確実なメモリ利用率監視法といえます。



間違ってる。完全に。

たぶんNTT OSSセンタという所は顧客と直接取引がある部署ではないのではないかと推測。さすがにこんなデタラメを説明する所があるとは信じがたい。

まず、ActiveとInactiveの違いは、メモリ不足発生時にInactiveのほうが先に回収可能性チェックをされる。という意味しかない。
Inactiveにもダーティーページ(ストレージが同期がとれていないページ)やmlockされたページなど捨てられないページは大量に混じっている。
また、Inactiveをチェックして、回収したりActiveに入れなおしたりして減ったInactiveのページ数はActiveからInactiveに落とすことにより、補充されるので、Activeであることも何も保障してない。
このエントリーをはてなブックマークに追加

なんか、io_setupで作ったカーネル内の構造体は継承されないのに、データ受け渡しようのリングバッファは継承さえる、かつ、man forkには何も書いてないという事で、

・リングバッファをmadvise(DONTFORK)しろ
・man forkに加筆しろ

と主張してみたが、どうやら通りそう。
このエントリーをはてなブックマークに追加

さっき、数分かけてHackしたdown_write_killable()が動かない。これなしでリリースするか
このエントリーをはてなブックマークに追加

http://www.ioremap.net/node/216

LinuxとFreeBSDでPOSIX mutexとsemaphoeのスループットを計測したよんというBlog.

・Linuxのmutex(futex)はFreeBSDより1.5倍くらい速いよ
・競合がないときは、なぜかsemaphoeが二倍速いけど意味不明
・まあどちらにしろ、全然スケールしないから、POSIX mutexはコンテンションがほとんどないように
 設計しないととんでもないことになるね
このエントリーをはてなブックマークに追加

だってさ
めちゃんこ、いい人やんけ

On Fri, 2009-04-10 12:49:13 +0200, Sam Ravnborg  wrote:
> It can...
> I'm after a one-stop place where we can locate cross compilers
> for all architectures that Linux supports so it is a much simpler
> task to actaully try to build our changes for as many architectures
> as we supports.

As long as nobody objects, I'll put snapshot compilers once a week to

http://www.kernel.org/pub/linux/kernel/people/jbglaw/cross_compilers

The first round is uploading right now, it should show up soon.

MfG, JBG

--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: The course of history shows that as a government grows, liberty
the second : decreases." (Thomas Jefferson)

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

本気で追加しようとしているから困る。そこはインプリ見直す所だろう。。
このエントリーをはてなブックマークに追加

これを使ってNOMMUもテストしてね♪
という意味らしい。

Blackfinなんて初めてみたよ。
このエントリーをはてなブックマークに追加

Josef Bacik が投稿したbtrfsのTODO(とど)リスト

Hello,

Trying to put together a list of TODO items for btrfs so we can update the wiki
page fully. So far these things are on the list

* Proper ENOSPC handling
* O_DIRECT support (without checksumming)
* AIO support
* Subvolume quotas and inherited space usage information
* Snapshot removal
* QA Suite for automated regression testing
* Reserved space for online fsck and the ability to add storage so that a
* background extent allocation check can proceed
* Additional ioctls to set per-inode attributes (nodatacow, nodatasum, etc)

So I think all of those are still true. Things that I know are being worked on
are

* async block group cacheing - me
* locking changes - Chris
* backref stuff - Yan

Som other things off the top of my head are

* a better way to cache block groups in general, for this I was thinking of a
bitmap or something like that per block group of free space
* space balancing. this will likely need to wait on proper ENOSPC handling
* grub support :)

Thats all that I can think of atm. Add things to the list if you think of them,
and hopefully we can update the wiki early next week. Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html


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

↑このページのトップヘ