プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

Life's too short to read through all this, but... このエントリーをはてなブックマークに追加

https://bugzilla.mozilla.org/show_bug.cgi?id=421482

------- Comment #123 From Andrew Morton 2008-05-22 21:26:02 PDT -------

Life's too short to read through all this, but...

yes, ext3 does suck-by-design. Always has.

I would commend the use of the sync_file_range() syscall on Linux. It
can be used to sync a subsection of a file and will not trigger the
write-the-whole-world behavior. It will just sync the stuff you want
sunk.



意訳:
このスレッドを全部読むには人生は短すぎる。でも・・・
Yes. ext3 はデザインからして最低です。


突然、firefoxのbugzillaに現れてext3を罵倒して去っていくAndrew。あんたサイコー
文脈もクソもねーな

この話のキモは、Andrewは最近までext3のメンテナーだったという所で。。。
そんなにメンテ苦痛だったのか(^^;


関連記事
スポンサーサイト
linux | 【2009-03-23(Mon) 16:10:15】 | Trackback:(0) | Comments:(0)

「グルジアやめてジョージアに」…ロシア語読みはイヤ!と このエントリーをはてなブックマークに追加

http://headlines.yahoo.co.jp/hl?a=20090321-00000531-yom-int

どうやらマジらしい。
グルジアというと、ゲームで翻訳会社が糞だったりするとよくジョージアになっていて、プゲラッとか笑い飛ばすメッカだったんだが、そうか、なくなってしまうのか。。

ちなみに、イギリスの守護聖人にもなっているジョージさんが、実は小アジアの今のトルコの人であることは、あまり知られていない。


関連記事
雑談 | 【2009-03-21(Sat) 15:52:12】 | Trackback:(0) | Comments:(0)

なんかTOMOYO記事にのった このエントリーをはてなブックマークに追加

http://japan.cnet.com/news/sec/story/0,2000056024,20390054-2,00.htm

しかも結構偉そうな事いってる。まあ世の中には自分そっくりな人が3人いると言いますしね

関連記事
linux | 【2009-03-18(Wed) 21:15:57】 | Trackback:(0) | Comments:(0)

自分の書いたパッチではまる このエントリーをはてなブックマークに追加

On Tue, 17 Mar 2009, Nick Piggin wrote:
> > Yes, my patch isn't realy solusion.
> > Andrea already pointed out that it's not O_DIRECT issue, it's gup vs fork
> > issue. *and* my patch is crazy slow :)
>
> Well, it's an interesting question. I'd say it probably is more than
> just O_DIRECT. vmsplice too, for example (which I think is much harder
> to fix this way because the pages are retired by the other end of
> the pipe, so I don't think you can hold a lock across it).

Well, only the "fork()" has the race problem.

So having a fork-specific lock (but not naming it by directio) actually
does make sense. The fork is much less performance-critical than most
random mmap_sem users - and doesn't have the same scalability issues
either (ie people probably _do_ want to do mmap/munmap/brk concurrently
with gup lookup, but there's much less worry about concurrent fork()
performance).

It doesn't necessarily make the general problem go away, but it makes the
_particular_ race between get_user_pages() and fork() go away. Then you
can do per-page flags or whatever and not have to worry about concurrent
lookups.

Linus


Andreaを見かねて助け船を出したつもりが、Linusから「むしろ kosaki パッチをマージすべきじゃね?」とか言われてアゴがはずれそう。
ごめんよAndrea,そんなつもりじゃなかったんだよー




関連記事
linux | 【2009-03-17(Tue) 11:16:28】 | Trackback:(0) | Comments:(0)

[英語] doable このエントリーをはてなブックマークに追加

そもそも単語の存在自体を知らなかったよ。

> splice() already has a callback for releasing the pages, so it's doable.

doable, maybe.



Linus: こうやったら出来るんじゃね?
Nick: ・・・たぶんね

とかいう感じで使う

関連記事
linux | 【2009-03-17(Tue) 09:12:42】 | Trackback:(0) | Comments:(0)

[英語] last resort このエントリーをはてなブックマークに追加

http://eow.alc.co.jp/last+resort/UTF-8/

・ last resort
最後{さいご}の手段{しゅだん}、苦肉{くにく}の策、伝家の宝刀、頼みの綱、最終審{さいしゅうしん}
・I've got to go with the last resort. : こうなったら最後の手段しかない



よく使うよね > 最後の手段

最初に見た時は、「前回行ったリゾート?話そらすなボケ!今はカーネルの話をしとるんじゃ!!」とか思ったものだが :-p

関連記事
英語 | 【2009-03-15(Sun) 18:33:25】 | Trackback:(0) | Comments:(0)

Rik van Riel からFacebook の招待状もらった このエントリーをはてなブックマークに追加

しかし、Facebookなんて普段つかってないので、フレンドは彼一人。オワタ\(^o^)/

関連記事
linux | 【2009-03-12(Thu) 20:21:08】 | Trackback:(0) | Comments:(0)

NILFSが2.6.30でマージ(予定) このエントリーをはてなブックマークに追加

Andrew MortonがNILFSを2.6.30でLinusに送ると発言。


On Wed, 11 Mar 2009 01:55:42 +0900 (JST)
Ryusuke Konishi wrote:

> I've been working for the past serveral months to take review comments
> and to continually solve users' problems come up in mainling list

Yes, the maintenance has been impressive.

> (thanks for all giving comments and feedbacks!). Also, I've tried to
> stabilize API and disk format to restrict additional changes and
> ensure backward compatibility.

Well. From the point of view of mainline linux, there is no
back-compatibility issue, because the fs hasn't been merged yet.

You perhaps have back-compatibility concerns for existing users of the
out-of-tree patch, but I'd encourage you to not worry about that too
much - there will be fairly few users and they are probably pretty
technical and will be able to cope with a migration. It's a _bit_ hard
on them but on the other hand, omitting back-compatibility code leads
to a better implementation for the long term.

What you should be more concerned about is forward-compatibility. What
arrangements do you presently have in place to be able to later alter the
on-disk format without causing too much disruption? Having a strong
design here will make changes easier to do and will lead to a better
filesystem.

Also.. Don't get _too_ concerned about freezing the on-disk format at
this time. You could put in a mount-time printk("the nilfs on-disk
format may change at any time - do not place critical data on a nilfs
filesystem") and we leave that in place for a few months while things
stabilise.

And yes, I was planning on sending nilfs in to Linus for 2.6.30 unless
someone has decent-sounding reasons to hold it back.
--
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 | 【2009-03-11(Wed) 09:56:01】 | Trackback:(0) | Comments:(0)

pagemapの使い方サンプル このエントリーをはてなブックマークに追加

http://selenic.com/repo/pagemap/

Matt Mackall が作ったサンプルだそうな

関連記事
linux | 【2009-03-10(Tue) 19:11:17】 | Trackback:(0) | Comments:(0)

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

今日、帰り際に投稿したパッチ、LKMLにccし忘れた気が強烈にする。
Ingoの事だから、即マージしちゃいそうな気がする。まずい

関連記事
雑談 | 【2009-03-09(Mon) 21:03:45】 | Trackback:(0) | Comments:(0)

ftraceのsplice対応のメール このエントリーをはてなブックマークに追加

貼っとく
(ちょっと古いけど)


RFC only, not for pulling, unless everyone is fine with these :-)

After telling the folks from Google that I had splice code that I needed
to get working, I finally got around to doing it.

Not only did I get the splice code working, but I also made a perl
script (might want to cover you eyes if you look at that code) that
can automagically create the output from the binary files reading
the format arguments in the /debugfs/tracing/events///format
file.

From previous patches, we have in include/trace/sched_event_types.h:

#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched

TRACE_EVENT_FORMAT(sched_switch,
TPPROTO(struct rq *rq, struct task_struct *prev,
struct task_struct *next),
TPARGS(rq, prev, next),
TPFMT("task %s:%d ==> %s:%d",
prev->comm, prev->pid, next->comm, next->pid),
TRACE_STRUCT(
TRACE_FIELD(pid_t, prev_pid, prev->pid)
TRACE_FIELD(int, prev_prio, prev->prio)
TRACE_FIELD_SPECIAL(char next_comm[TASK_COMM_LEN],
next_comm,
TPCMD(memcpy(TRACE_ENTRY->next_comm,
next->comm,
TASK_COMM_LEN)))
TRACE_FIELD(pid_t, next_pid, next->pid)
TRACE_FIELD(int, next_prio, next->prio)
),
TPRAWFMT("prev %d:%d ==> next %s:%d:%d")
);

By making that, we automagically get this file:

# cat /debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 29
format:
field:unsigned char type; offset:0; size:1;
field:unsigned char flags; offset:1; size:1;
field:unsigned char preempt_count; offset:2; size:1;
field:int pid; offset:4; size:4;
field:int tgid; offset:8; size:4;

field:pid_t prev_pid; offset:12; size:4;
field:int prev_prio; offset:16; size:4;
field special:char next_comm[TASK_COMM_LEN]; offset:20; size:16;
field:pid_t next_pid; offset:36; size:4;
field:int next_prio; offset:40; size:4;

print fmt: "prev %d:%d ==> next %s:%d:%d"


Now with this patch set, we create a way to read the ftrace ring buffers
directly, as a binary page. Splice has been used such that the user
could splice the ring buffers without need to copy the pages.
The pages are taken from the ring buffers and can be placed directly
into files, without extra copies.

# ls /debug/tracing/binary_buffers/
0 1 2 3 4 5 6 7

One can either just use the read/write to grab live data from these
buffers, or they could use splice. I have a simple file that reads
this buffers using splice. Note, it only runs on one file, you
can make multiple copies to run more. The ring buffers in ftrace
are per cpu and they are not dependent on each other.

Also, if there is no data in the buffer, it returns -EAGAIN.

# find /debug/tracing/events -name 'type' | while read f; do
> echo raw > $f; done

# find /debug/tracing/events -name 'enable' | while read f; do
> echo 1 > $f; done

# ./splice /debug/tracing/binary_buffers/0 /tmp/buf-0

Yes you can run multiple instances of this on different buffers.

# ./rb-read.pl /tmp/buf-0

produces:

0 [000] 7071.936459: (irq_handler_entry) irq 48
0 [000] 7071.936462: (irq_handler_exit) irq 48 ret 1
0 [000] 7071.988801: (sched_signal_send) sig: 14 task 0
0 [000] 7071.988813: (sched_wakeup) task 0 success=1
0 [000] 7071.988823: (sched_switch) prev 0:140 ==> next ntpd:6582272:0
3303 [000] 7071.988916: (sched_switch) prev 0:120 ==> next swap:7497072:0
0 [000] 7072.020370: (sched_wakeup) task 0 success=1
0 [000] 7072.020407: (sched_switch) prev 0:140 ==> next even:808416116:0
16 [000] 7071.936157: (sched_switch) prev 0:115 ==> next swap:7497072:0

Notice the "(sched_switch)" lines.

The splice C code:
http://www.kernel.org/pub/linux/kernel/people/rostedt/splice.c

The perl script to parse:
http://www.kernel.org/pub/linux/kernel/people/rostedt/rb-read.pl

And yes I know, they are both ugly :-p

The following patches are in:

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git

branch: rfc/splice/tip/tracing/ftrace


Steven Rostedt (5):
ring-buffer: reset write field for ring_buffer_read_page
ring-buffer: fix ring_buffer_read_page
ring-buffer: replace sizeof of event header with offsetof
ring-buffer: make ring_buffer_read_page read from start on partial page
tracing: add binary buffer files for use with splice

----
include/linux/ring_buffer.h | 7 +-
kernel/trace/ring_buffer.c | 118 +++++++++++++------
kernel/trace/trace.c | 274 +++++++++++++++++++++++++++++++++++++++++-
kernel/trace/trace.h | 1 +
4 files changed, 357 insertions(+), 43 deletions(-)
--
--
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 | 【2009-03-09(Mon) 10:05:57】 | Trackback:(0) | Comments:(0)

[英語] don't hesitate to tell. このエントリーをはてなブックマークに追加

> > Could you please update Documentation/ftrace.txt?
> > I guess many user interesting this patch. :)
>
> Yeah, it has become a really nice feature this way. As i told it
> to K.Prasad before: we need this tracer because the data tracer
> will likely become the most common usecase of this facility. We
> will get the hw breakpoints facility tested and used.
>
> And in fact we can go one step further: it would also be nice to
> wire it up with the ftrace histogram code: so that we can get
> usage histograms of kernel symbol read/write activities without
> the overhead of tracing. (The branch tracer already has this.)
>
> Especially frequently used variables generate a _lot_ of events.
>
> Ingo

Right, it will even be an occasion to improve and further test
the histogram tracing.
K. Prasad if you need some help on how to use it, don't hesitate to tell.

Frederic.



please don't hesitate to tell. で遠慮せずに聞いてね。という慣用句らしい

追記:
id:kazuhookuさんから、「don't hesitate to ask の間違いでなくて? 」とツッコミをいただいた。
たぶん正当英語的にはaskなんだと思う。LKMLはウソ英語の巣窟なので、細かいことは気にしてはいけないんだという、いいサンプルになってしまった。


関連記事
英語 | 【2009-03-08(Sun) 20:10:42】 | Trackback:(0) | Comments:(0)

SystemTapがtracepoint対応完了したそうな このエントリーをはてなブックマークに追加

なんか、こんなアナウンスでてた。
あとは、tracepointをカーネル本体に埋め込んでいくだけなのだが、これってたぶんオレの宿題なんだよなぁ・・・

Hi All,

I just pushed out support for kernel tracepoints in systemtap -- a copy
of the manpage section is included below for reference. Try this
command to see what's available in your kernel:
stap -l 'kernel.trace("*")'

On Fedora rawhide, the kernel does have tracepoints enabled, but the
kernel-devel package is missing the headers needed to define the
tracepoints. This has been fixed in the package spec now, so the next
kernel package should be ready to go. If you're impatient, you can also
grab the source rpm and copy include/trace into
/usr/src/kernels/$(uname -r)/include/trace/.

RHEL5 U3 also contains tracepoints, and is also missing the headers from
kernel-devel. Again, copying the files from the source RPM should let
you use them now. I don't have an ETA for when the official package
might be updated though...

For other distributions or custom kernels, YMMV, but anything 2.6.28+
should have at least a few tracepoints available.

As always, any feedback is welcome...

Thanks,

Josh


TRACEPOINTS

This family of probe points hooks up to static probing trace-
points inserted into the kernel or modules. As with markers,
these tracepoints are special macro calls inserted by kernel de-
velopers to make probing faster and more reliable than with
DWARF-based probes, and DWARF debugging information is not re-
quired to probe tracepoints. Tracepoints have an extra advan-
tage of more strongly-typed parameters than markers.

Tracepoint probes begin with kernel. The next part names the
tracepoint itself: trace("name"). The tracepoint name string,
which may contain the usual wildcard characters, is matched
against the names defined by the kernel developers in the trace-
point header files.

The handler associated with a tracepoint-based probe may read
the optional parameters specified at the macro call site. These
are named according to the declaration by the tracepoint author.
For example, the tracepoint probe kernel.trace("sched_switch")
provides the parameters $rq, $prev, and $next. If the parameter
is a complex type, as in a struct pointer, then a script can ac-
cess fields with the same syntax as DWARF $target variables.
Also, tracepoint parameters cannot be modified, but in guru-mode
a script may modify fields of parameters.

The name of the tracepoint is available in $$name, and a string
of name=value pairs for all parameters of the tracepoint is
available in $$vars.



関連記事
linux | 【2009-03-07(Sat) 17:48:23】 | Trackback:(0) | Comments:(0)

GEMを使うとdrop_cacheが出来なくなる。というバグ報告が増えた このエントリーをはてなブックマークに追加

Hello!

I have a small problem. Maybe its just a misunderstanding but I cant
solve it.

I think that writing "3" to drop_caches should drop all buffers and
caches which are already written. So its recommended to put a "sync"
infront of it.
So I did "free -m ; sync ; echo 3 > /proc/sys/vm/drop_caches ; free -m"
And it gave me:

total used free shared buffers cached
Mem: 3950 3922 28 0 1 879
-/+ buffers/cache: 3041 909
Swap: 5342 205 5136

total used free shared buffers cached
Mem: 3950 3907 43 0 0 864
-/+ buffers/cache: 3041 908
Swap: 5341 206 5135

So the buffer was 1 and is 0 afterthat. But cached is at 879 MB before
and is still 864 MB (!!!) after that!

I am at swappiness=0 and when I remove and readd one swap-partition
after another (so there is always swap). It will keep the cached and
put the swapped memory on other swaps?!

I _think_ thats not the way it should go?

It would be really kind if someone could explain that issue and
what "cached" is at all!

Have a nice day...
Markus

PS: Please CC me as I am not subscribed.



2.6.28でGEMが入ってからメモリが足りなくなった-。リークだーと騒ぐ人が増えたね。


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

してもcached 欄が減らないぞーというわけ。

さて、このcached欄であるが、/proc/meminfoの "Cached:"フィールドの数字を表示している。
で、以下の結果をみると


I rebooted in console without the nvidia-module loaded and have the same
results (updated to 2.6.28.7 btw):
# sync ; echo 3 > /proc/sys/vm/drop_caches ; free -m ; cat /proc/meminfo
total used free shared buffers
cached
Mem: 3950 1647 2303 0 0
924
-/+ buffers/cache: 722 3228
Swap: 5890 0 5890
MemTotal: 4045444 kB
MemFree: 2358944 kB
Buffers: 544 kB
Cached: 946624 kB
SwapCached: 0 kB
Active: 1614756 kB
Inactive: 7632 kB
Active(anon): 1602476 kB
Inactive(anon): 0 kB
Active(file): 12280 kB
Inactive(file): 7632 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 6032344 kB
SwapFree: 6032344 kB
Dirty: 72 kB
Writeback: 32 kB
AnonPages: 675224 kB
Mapped: 17756 kB
Slab: 19936 kB
SReclaimable: 9652 kB
SUnreclaim: 10284 kB
PageTables: 8296 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8055064 kB
Committed_AS: 3648088 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 10616 kB
VmallocChunk: 34359716459 kB
DirectMap4k: 6080 kB
DirectMap2M: 4188160 kB


Cachedと{In}Active(file) が合ってないように見えるが、これはtmpfs用のページが{In}Active(anon)にチャージされる仕様のため。
ようするに Cached:の900MはほとんどがtmpfsファイルでActive(anon)にチャージされていると考えるとつじつまがある。

で、このあと、そんなのマウントしてないとか議論になるのだが、Intelドライバつかっていると、カーネル内部でGEM用にこっそりマウントしてこっそり確保しまくるんだな。これが。

だから、ドライバが900Mも使うな!と抗議するのが正しい




http://bugs.freedesktop.org/show_bug.cgi?id=20404

関連記事
linux | 【2009-03-05(Thu) 09:33:52】 | Trackback:(0) | Comments:(1)

[英語] address = 対処する このエントリーをはてなブックマークに追加

Tom Zanussi pointed out that the simple TRACE_FIELD was not enough to
record trace data that required memcpy. This patch addresses this issue
by adding a TRACE_FIELD_SPECIAL. The format is similar to TRACE_FIELD
but looks like so:



「パッチ address プロブレム名」 で、このパッチはこのプロブレムに(取り組む|対処する)パッチだよん。
という風に書く。


関連記事
英語 | 【2009-03-03(Tue) 09:26:48】 | Trackback:(0) | Comments:(1)

「動詞がない文章を書く人もいる,英語の壁は気にするな」 このエントリーをはてなブックマークに追加

http://itpro.nikkeibp.co.jp/article/COLUMN/20090227/325643/?ST=lin-os&P=1

ITpro様に第10回The Linux Foundation Japan Symposiumの様子をとりあげていただきました。
しかし、恥ずかしい煽り文句を選ばれてしまったものです。


関連記事
linux | 【2009-03-03(Tue) 08:07:04】 | Trackback:(0) | Comments:(4)

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

貼っとく。



* Linus Torvalds wrote:

> On Tue, 24 Feb 2009, Dave Hansen wrote:
> >
> > Yeah, that's a good point. Are we sure that's what is
> > happening here, though? That's one thing a profile would
> > hopefully help with.
>
> One thing to note is that _if_ it's purely an issue of
> nontemporal stores vs normal stores, then profiling is very
> likely going to be almost entirely useless. You'll get
> "results", but the results have nothing what-so-ever to do
> with reality or anything interesting.
>
> The nontemporal stores may stand out in the profiles, but the
> actual performance impact will be all about whether totally
> unrelated code got cache misses or not. Quite often those
> cache misses will also be in user mode, and very possibly in
> other processes.
>
> So profiles can certainly be interesting, but if Salman says
> that his patch makes a difference for his benchmark, then
> profiling is almost certainly not interesting FOR THAT PATCH.
> It's interesting mainly as a way to look at whether there are
> then also _other_ issues that are worth addressing (ie the
> whole atime thing is in a whole different dimension and an
> independent issue).

a 'perfstat' run would certainly be interesting (for cases where
a pure /usr/bin/time run is inconclusive), comparing the
unpatched and patched kernel.

That way we can see summary counts for the whole workload, like:

-----------------------------------------------
| Performance counter stats for './mmap-perf' |
-----------------------------------------------
| |
| x86-defconfig | PARAVIRT=y
|------------------------------------------------------------------
|
| 1311.554526 | 1360.624932 task clock ticks (msecs) +3.74%
| |
| 1 | 1 CPU migrations
| 91 | 79 context switches
| 55945 | 55943 pagefaults
| ............................................
| 3781392474 | 3918777174 CPU cycles +3.63%
| 1957153827 | 2161280486 instructions +10.43%
| 50234816 | 51303520 cache references +2.12%
| 5428258 | 5583728 cache misses +2.86%
|
| 437983499 | 478967061 branches +9.36%
| 32486067 | 32336874 branch-misses -0.46%
| |
| 1314.782469 | 1363.694447 time elapsed (msecs) +3.72%
| |
-----------------------------------

Such a comparison of would certainly be more meaningful for such
things than a profile.

Salman, if you are interested in doing a perfstat comparison,
just pick up a tip:master kernel [perfcounters are
default-enabled in it]:

http://people.redhat.com/mingo/tip.git/README

and run perfstat on it (as root, to get the kernel-mode counts
too):

http://redhat.com/~mingo/perfcounters/perfstat.c

Ingo
--
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 | 【2009-03-01(Sun) 18:43:43】 | Trackback:(0) | Comments:(0)

LTPのテストの作り方のHOWTOの場所 このエントリーをはてなブックマークに追加

KOSAKI Motohiro, there is a small introduction guide for how to do it.

http://ltp.sourceforge.net/documentation/technical_papers/node4.php

CAI Qian




関連記事
linux | 【2009-03-01(Sun) 17:34:55】 | Trackback:(0) | Comments:(0)

Christoph Lameter の page allocator / slab allocator microbenchmarks の場所 このエントリーをはてなブックマークに追加

On Sun, 22 Feb 2009, Mel Gorman wrote:

> I haven't run a page-allocator micro-benchmark to see what sort of figures
> that gives. Christoph, I recall you had some sort of page allocator
> micro-benchmark. Do you want to give it a shot or remind me how to use
> it please?

The page allocator / slab allocator microbenchmarks are in my VM
development git tree. The branch is named tests.

http://git.kernel.org/?p=linux/kernel/git/christoph/vm.git;a=shortlog;h=tests



関連記事
linux | 【2009-03-01(Sun) 17:34:01】 | Trackback:(0) | Comments:(0)

特許違反で訴えるぞ このエントリーをはてなブックマークに追加

On Fri, 27 Feb 2009, Steven Rostedt wrote:
>
> HAHAHAHHAAAA!!!! My evil scheme is working! I post some sub-optimal code,
> and have others do the nasty work for me!!!!
>
> Oh, did I just say that out loud?

Not only that, I will also sue you for my patent on that algorithm.

Linus



Steven Rostedt(ftraceの作者)がAndrew Mortonから、この設計はそもそもダメじゃね?とレビューコメントもらったとき、開き直って「いいもん。evilでも動くもん!!」と暴れた後「うるさく言い過ぎた?」
と書いたのに対してのLinusの言葉。

「それだけじゃなく、僕のアルゴリズム特許に違反しているね」


あんた、自覚あるなら、暴れるのやめなや

関連記事
linux | 【2009-03-01(Sun) 14:41:09】 | Trackback:(0) | Comments:(0)

[英語] Am i missing anything? このエントリーをはてなブックマークに追加

オレ、なんか見逃してるかい?

ってこと。レビューで相手に反論をひとしきり書いたあとにつける、常套句。

関連記事
英語 | 【2009-03-01(Sun) 14:12:32】 | Trackback:(0) | Comments:(0)

[英語] artifact このエントリーをはてなブックマークに追加

D&Dの世界では「つおい」マジックアイテムぐらいの意味だが、LKMLだと「作為的」の意味で使われる。
ちょっと(ベンチマークの作りが)作為的じゃない?とかそういう用途

D&Dのアーティファクトといえば・・(脱線なので以下略)

関連記事
英語 | 【2009-03-01(Sun) 14:06:25】 | Trackback:(0) | Comments:(0)

cache pollution aware __copy_from_user_ll() ふたたび このエントリーをはてなブックマークに追加

"Performance regression in write() syscall" というスレッドでcopy_user_nocache() を蒸し返している。
要約すると


- Andi Kleenが入れた、x86_64版 __copy_user_nocache()のせいでUnixbenchの性能が落ちたよ
- Unixbenchはwriteシステムコールがページキャッシュに書くまでの時間しか計っていなくて
  まったく意味のない区間を計測してる。クソだよ
- Andi Kleenのパッチは性能測定値が書いてなくて、評価できないよ。
- あれは、x86_32からの単純な移植だから、x86_32のときに評価済みだよ。git commitはこれだよ
See "x86: cache pollution aware __copy_from_user_ll()",
commit c22ce143d15eb288543fe9873e1c5ac1c01b69a1.
- で、冷静に考えるとページサイズ以下のファイルはshell scriptがスクラッチパッド的に使う
  テンポラリファイルが多いから、キャッシュした方がお得だよ
- んじゃ、コピーサイズに応じて動作変えるか


Linusからのx86_32版 git commit が出てくるの速いのなんのって。印象深かったんだな


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