プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

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

GregKHがsysfsと/proc/mountsのパッチの両方を拾ったので2.6.31で修正される見込み。
ええ、非互換です


関連記事
linux | 【2009-04-10(Fri) 08:35:39】 | Trackback:(0) | Comments:(0)

[linux-btrfs] btrfs vs ext4 benchmark このエントリーをはてなブックマークに追加

IBMのサーバでbtrfsとext4のベンチとったらbtrfsはクソ遅かったぜ。という話。


Hi,

here are some tests on an IBM server with btrfs vs. ext4.

Kernel: 2.6.29.1
Benchmark software: compilerbench with options -i 10 -r 30
CPU: Intel Xeon Quadcore E5310
Chipset: Intel 5000
Memory: 4 GB FB-DIMM DDR2-667
HDDs: 2x WD6400AAKS @ Raid0
Storage Controller: IBM Serveraid 8k

btrfs Result:

intial create total runs 10 avg 50.89 MB/s (user 0.85s sys 2.59s)
create total runs 5 avg 23.62 MB/s (user 0.82s sys 2.55s)
patch total runs 4 avg 11.35 MB/s (user 0.38s sys 2.22s)
compile total runs 7 avg 66.33 MB/s (user 0.19s sys 1.32s)
clean total runs 4 avg 195.76 MB/s (user 0.03s sys 0.50s)
read tree total runs 2 avg 11.99 MB/s (user 0.66s sys 2.59s)
read compiled tree total runs 1 avg 30.14 MB/s (user 0.88s sys 3.64s)
delete tree total runs 2 avg 10.79 seconds (user 0.43s sys 3.39s)
no runs for delete compiled tree
stat tree total runs 4 avg 9.62 seconds (user 0.41s sys 1.03s)
stat compiled tree total runs 1 avg 10.51 seconds (user 0.49s sys 1.19s)

ext4 Result:

intial create total runs 10 avg 96.09 MB/s (user 0.77s sys 1.34s)
create total runs 5 avg 50.84 MB/s (user 0.82s sys 1.20s)
patch total runs 4 avg 20.17 MB/s (user 0.28s sys 1.04s)
compile total runs 7 avg 94.39 MB/s (user 0.17s sys 1.07s)
clean total runs 4 avg 959.66 MB/s (user 0.03s sys 0.11s)
read tree total runs 2 avg 14.67 MB/s (user 0.78s sys 1.26s)
read compiled tree total runs 1 avg 31.96 MB/s (user 0.87s sys 2.31s)
delete tree total runs 2 avg 2.14 seconds (user 0.34s sys 0.81s)
no runs for delete compiled tree
stat tree total runs 4 avg 1.82 seconds (user 0.40s sys 0.35s)
stat compiled tree total runs 1 avg 1.83 seconds (user 0.35s sys 0.33s)

Best regards,

Morten

--
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



Chris Mason の反論(いいわけ?)は以下

The difference in initial create times is pretty surprising. My guess
is that single spindle duplication of metadata hurts more on this raid
array.

For the other times compilebench was actually written to make btrfs look
bad. The main goal was to age and fragment the metadata, while
constantly clearing out the caches used to make things fast.

IOW, it was meant to be a worst case ;) Some of these numbers look like
the cache clearing wasn't hitting ext4. I'll rerun the test against
ext4 next week.




関連記事
linux | 【2009-04-08(Wed) 17:21:53】 | Trackback:(0) | Comments:(0)

ext3のデフォルトモードがwritebackに変わっちゃった件について このエントリーをはてなブックマークに追加

ext3のlatency問題に嫌気がさした、linus。
とうとうext3のデフォルトモードをorderedからwritebackに変えちゃった。サインが彼一人なのを見ても分かるように、誰にも相談せずに・・・

commit bbae8bcc49bc4d002221dab52c79a50a82e7cd1f
Author: Linus Torvalds
Date: Mon Apr 6 17:16:47 2009 -0700

ext3: make default data ordering mode configurable

This makes the defautl ext3 data ordering mode (when no explicit
ordering is set) configurable, so as to allow people to default to
'data=writeback' and get the resulting latency improvements.

This is a non-issue if a filesystem has been explicitly set to some
ordering (with 'tune2fs').

Signed-off-by: Linus Torvalds



コードは以下のような感じなので、カーネルのコンパイル時オプションを設定するか
tune2fs を使うかでordered mode の世界に戻ることが出来る模様

diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 9e5b8e3..599dbfe 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -44,6 +44,12 @@
#include "acl.h"
#include "namei.h"

+#ifdef CONFIG_EXT3_DEFAULTS_TO_ORDERED
+ #define EXT3_MOUNT_DEFAULT_DATA_MODE EXT3_MOUNT_ORDERED_DATA
+#else
+ #define EXT3_MOUNT_DEFAULT_DATA_MODE EXT3_MOUNT_WRITEBACK_DATA
+#endif
+
static int ext3_load_journal(struct super_block *, struct ext3_super_block *,
unsigned long journal_devnum);
static int ext3_create_journal(struct super_block *, struct ext3_super_block *,
@@ -1919,7 +1925,7 @@ static int ext3_fill_super (struct super_block *sb, void *data, int
cope, else JOURNAL_DATA */
if (journal_check_available_features
(sbi->s_journal, 0, 0, JFS_FEATURE_INCOMPAT_REVOKE))
- set_opt(sbi->s_mount_opt, ORDERED_DATA);
+ set_opt(sbi->s_mount_opt, DEFAULT_DATA_MODE);
else
set_opt(sbi->s_mount_opt, JOURNAL_DATA);
break;




関連記事
linux | 【2009-04-08(Wed) 16:24:14】 | Trackback:(0) | Comments:(0)

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

気が変わって、LKMLでバトルしてみることにした。Ruby嫌いじゃないし

以下の修正パッチで直ることは確認した


--
fs/sysfs/file.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 289c43a..4a302f8 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -446,11 +446,11 @@ static unsigned int sysfs_poll(struct file *filp, poll_table *wait)
if (buffer->event != atomic_read(&od->event))
goto trigger;

- return 0;
+ return DEFAULT_POLLMASK;

trigger:
buffer->needs_read_fill = 1;
- return POLLERR|POLLPRI;
+ return DEFAULT_POLLMASK|POLLERR|POLLPRI;
}

void sysfs_notify_dirent(struct sysfs_dirent *sd)


関連記事
linux | 【2009-04-08(Wed) 02:11:29】 | Trackback:(0) | Comments:(5)

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

なんか、何年かぶりに胃痛で眠れない。
最近体調わるいなぁ

困ったことにこいつを殴れば直る。と言えるような明確なストレス源が思いつかないので直るメドがたたない。
まあ、分かっていても殴れない事の方が多い気もするが


関連記事
雑談 | 【2009-04-08(Wed) 00:35:22】 | Trackback:(0) | Comments:(0)

akrさんといえば このエントリーをはてなブックマークに追加

ttyの件が絶賛放置中だ。暇をみつけて再開しないと。
うぐぐ、どんどん宿題がたまっていくなぁ

tty は元が汚いので、もっと綺麗になおして♪とかレビューコメントがつくとメドイのだよ

関連記事
linux | 【2009-04-07(Tue) 21:31:28】 | Trackback:(0) | Comments:(0)

Ruby でsysfsのファイルが読めない件について このエントリーをはてなブックマークに追加

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

昨日ひろのぶさんに指摘されたのだが、GNU/Linux で /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies がうまく読めないという。

% ruby -ve '
Thread.new { sleep }
File.read("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies")
'
ruby 1.9.2dev (2009-03-13 trunk 22936) [i686-linux]
(ここでブロックして終わらない)



ほほー。でコードをチェックしてみる

fs/sysfs/file.c の以下の部分が原因っぽげ。
内部データが変わって、以前と違うデータが読めるようになった時しか poll が値を返していない。


/* Sysfs attribute files are pollable.  The idea is that you read
* the content and then you use 'poll' or 'select' to wait for
* the content to change. When the content changes (assuming the
* manager for the kobject supports notification), poll will
* return POLLERR|POLLPRI, and select will return the fd whether
* it is waiting for read, write, or exceptions.
* Once poll/select indicates that the value has changed, you
* need to close and re-open the file, or seek to 0 and read again.
* Reminder: this only works for attributes which actively support
* it, and it is not possible to test an attribute from userspace
* to see if it supports poll (Neither 'poll' nor 'select' return
* an appropriate error code). When in doubt, set a suitable timeout value.
*/
static unsigned int sysfs_poll(struct file *filp, poll_table *wait)
{
struct sysfs_buffer * buffer = filp->private_data;
struct sysfs_dirent *attr_sd = filp->f_path.dentry->d_fsdata;
struct sysfs_open_dirent *od = attr_sd->s_attr.open;

/* need parent for the kobj, grab both */
if (!sysfs_get_active_two(attr_sd))
goto trigger;

poll_wait(filp, &od->poll, wait);

sysfs_put_active_two(attr_sd);

if (buffer->event != atomic_read(&od->event))
goto trigger;

return 0;

trigger:
buffer->needs_read_fill = 1;
return POLLERR|POLLPRI;
}



コメントを読むと意図した feature なんだと言っているようなので、Linux側を直すのは筋が悪そう。たぶん、既存のsysfs監視ツールが壊れる。
どうするのが一番害がすくない直し方なのか、後でまた考える



関連記事
linux | 【2009-04-07(Tue) 21:20:19】 | Trackback:(0) | Comments:(0)

[LKML] Off topic: Numactl "distance" wrong このエントリーをはてなブックマークに追加

オフトピックと言いつつ、全然オフトピックじゃない罠

オプテロン4コアで、ノード間距離が20になっているので遅いよ。という報告

Sorry for an off topic, but I'm hoping somebody can point me in the
right direction of where to direct this question...

I have an Opteron system where I've seen the HW diagrams, and each of
4 sockets is directly connected (HT) to two other sockets, and two HT
hops away from a third (i.e. a simple square topology, no X in the
middle).

Yet, "numactl --hardware" shows but one hop to each socket:

# numactl --hardware
...
node 0 1 2 3
0: 10 20 20 20
1: 20 10 20 20
2: 20 20 10 20
3: 20 20 20 10

I know this is wrong.

Who would be the right person (or list) to talk about this?

I'm using the latest numactl 2.0.3-rc2 source and a 2.6.29.1 kernel.

Thanks,

Chris
--
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/



Opteronのマザーボードが適切にPXMを報告してる所なんか見たことねーぜ。という凄い返事が

IIRC, the motherboard/BIOS is supposed to report numa distances through
the PXM ACPI method. But I have never seen any opteron box do it
properly. So you just get 10 for "local" and 20 for "remote". Some
Itanium machines however report actual distances.

Brice



で、
たぶん、SLITが入ってないおかしなACPI BIOSなので、10/20にカーネルが設定してるんじゃね?(昔はNUMA=ラージサーバだったので、ラージサーバ向けにfallbackするのが正しい)とか、sysfsとかで設定できるようにしない?とか議論がつづく

が、結論は出ないまま終わる。
ようするに、Opeteron使うやつがアホってことけ?


でも、よく考えてみるとノード間距離が影響を与えるのはスケジューラのマイグレーションコストの計算と、メモリのzone_reclaim_modeのデフォルト値の計算。

・CPUのマイグレーションコストは一般のワークロードでは性能に影響しない
・20だとzone_reclaim_modeは変わらない

ので、影響ないな。どうでもいい






関連記事
linux | 【2009-04-07(Tue) 10:58:49】 | Trackback:(0) | Comments:(0)

帰ってきたkernel watch このエントリーをはてなブックマークに追加

明日、掲載予定

関連記事
linux | 【2009-04-07(Tue) 10:22:07】 | Trackback:(0) | Comments:(0)

[LKML] procps and new kernel fields このエントリーをはてなブックマークに追加

Dave Hansenが/proc/meminfoのカラムが増えたのに対応してprocpsを改良したよ。ってメールしてた

There was a very brief conversation about this a year ago or so. We've
got a ton of newfangled output in /proc/meminfo, but procps ignores most
of it. There's also a bunch of types of memory that don't get shown by
the various procps commands these days.

http://marc.info/?l=linux-mm&m=120496901605830&w=2

Novell has integrated that patch into procps which has the side-effect
that now reclaimable slab and unstable NFS pages are included in the
'cached' output of vmstat and free.

https://bugzilla.novell.com/show_bug.cgi?id=405246

The most worrisome side-effect of this change to me is that we can no
longer run vmstat or free on two machines and compare their output.

At the same time, we have machines that have dozens of GB of slab
objects that are mostly reclaimable. Yet, 'free' and 'vmstat' basically
ignore slab. Surely we need to find some way to report on those,
especially since we can now break out {un,}reclaimable slab.

We also have "new" memory use like unstable NFS pages. How should we
account for those?

I'd love to see an --extended output from things like vmstat. It could
include wider output since fitting in 80 columns just isn't that
important any more, and my 256GB machine's output really screws up the
column alignment. We could also add some information which is in
addition to what we already provide in order to account for things like
slab more precisely.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: email@kvack.org



パッチのキモは以下なのだが、SwapCacheをCacheに含めていいかは微妙なんだけどな
SwapCacheの意味は、swap outできるように、リザーブしたスワップエントリ数(not 本当に使った数)
という意味なので、SwapCacheと捨てられるAnonページであることはイコールではない。

SwapCacheであることはマップされてないことは保証されてないから、ページにSwapCache属性をつけたあとに頻繁にアクセスされれば、捨てないし。
まあ、SwapCacheのほとんどケースはswap-in処理の時にreadaheadで読んだスワップページが予測ミスで誰からもマップされないまま捨てられていくというパターンが一番多い気がするので近似値としてはいいのかもしれない。

@@ -603,6 +615,7 @@
}
kb_swap_used = kb_swap_total - kb_swap_free;
kb_main_used = kb_main_total - kb_main_free;
+ kb_main_cached += kb_slab_reclaimable + kb_swap_cached + kb_nfs_unstable;
}




関連記事
linux | 【2009-04-07(Tue) 09:27:52】 | Trackback:(0) | Comments:(0)

[LKML] IRQF_SAMPLE_RANDOM question... このエントリーをはてなブックマークに追加

2.6.28でネットワークドライバがランダムエントロピーを提供しなくなったので、組込み機器でエントロピー供給源がなくなっちゃった。という話。

Robin Getzが以下の質問をなげて

Although there was some discussion
http://thread.gmane.org/gmane.linux.kernel/680723

about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of
2008, but they still appears to be there in 2.6.29.

drivers/net/ibmlana.c
drivers/net/macb.c
drivers/net/3c523.c
drivers/net/3c527.c
drivers/net/netxen/netxen_nic_main.c
drivers/net/cris/eth_v10.c
drivers/net/xen-netfront.c
drivers/net/atlx/atl1.c
drivers/net/qla3xxx.c
drivers/net/tg3.c
drivers/net/niu.c

So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others
(like the Blackfin) networking drivers - will it get rejected?

We have lots of embedded headless systems (no keyboard/mouse, no soundcard, no
video) systems with *no* sources of entropy - and people using SSL.

I didn't really find any docs which describe what should have
IRQF_SAMPLE_RANDOM on it or not. I did find Matt Mackall describing it as:
> We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely
> trusted unobservable entropy source' which is obviously wrong for
> network devices but is right for some other classes of device.

Currently - I see most things I see using IRQF_SAMPLE_RANDOM would also fail
the "completely unobservable" test. Other than the TRNG that are inside the
CPU - what does pass?

I can put a scope/analyser on a device - and look at the touchscreens, serial
devices, USB, all without cracking the case.

drivers/block/xen-blkfront.c: Xen virtual block device frontend
drivers/i2c/busses/i2c-pmcmsp.c: PMC MSP TWI/SMBus/I2C driver
drivers/input/keyboard/bf54x-keys.c: Keypad driver for BF54x Processors
drivers/input/keyboard/gpio_keys.c: Keyboard driver for CPU GPIOs
drivers/input/serio/hp_sdc.c: HP i8042-based SDC Driver
drivers/input/touchscreen/wm97xx-core.c: WM97xx Core - Touch Screen
drivers/serial/mpc52xx_uart.c: Freescale MPC52xx PSC UART
drivers/serial/uartlite.c: Xilinx uartlite serial driver
drivers/usb/gadget/omadrivers/usb/gadget/omap_udc OMAP UDC driver

If I want to get more intrusive (expensive) - I can look at SPI, I2C, and
other things that only might be observable at the PCB level (including things
that are inside the chipset).

What are the guidelines for including IRQF_SAMPLE_RANDOM?

Thanks
-Robin
--
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/




Jeff Garzik が端的に説明。
ようするに、ネットワークパケットはアタッカーからコントロール可能だからエントロピー供給源としては好ましくないよ。ってこと

IMO it's not observation but rather that a remote host is essentially
your source of entropy -- which means your source of entropy is
potentially controllable or influenced by an attacker.

Furthermore, with hardware interrupt mitigation, non-trivial traffic
levels can imply that interrupts are delivered with timer-based
regularity. This, too, may clearly be influenced by a remote attacker.

Thus I think IRQF_SAMPLE_RANDOM should be banned from network drivers...
but that is not a universal opinion.

Jeff



で、その後、当然の疑問としてSven-Haegarが
おいおい、ハードウェアランダムジェネレータを搭載しないサーバをsshオペレーションで運用すると、キーボードとか一切触らないから、エントロピーが供給されなくなっちゃうぜ。
/dev/random が無限にブロックするぜ。
と苦情が。

> Btw, perhaps not the perfect question in this thread:
> But what should we use to keep servers running without a hardware rng
> available and without any external input besides the network?
> After having ssh and openvpn die because of no random and having
> the machines like dead and unreachable for me I use "ln -sf
> /dev/urandom /dev/random", but that does not feel so good.

We see this question every time IRQF_SAMPLE_RANDOM is discussed.

There is plenty of entropy data available, you just have to look
around... Google around for "EGD", video entropy daemon, audio entropy
daemon, etc...

Even headless servers have entropy sources if you look hard enough.

Jeff



んで、答え。
グーグルだって出来るんだから、君はハードのエントロピー供給源を何か見つけれるはずだ・・・・

おいおい、グーグルはIAサーバなんだからハードエントロピー供給源ありじゃん。うそつき。

関連記事
linux | 【2009-04-07(Tue) 09:13:51】 | Trackback:(0) | Comments:(2)

とりあえず、アレだ このエントリーをはてなブックマークに追加

MathieuとIngoには話をつけたので、kernel にtracepointを大量に埋め込んじゃうぜ計画は近々日の目を見そうな気がする

関連記事
linux | 【2009-04-01(Wed) 22:58:17】 | Trackback:(0) | Comments:(0)

米シリコン・グラフィックス、連邦破産法11条の適用を申請 このエントリーをはてなブックマークに追加

http://jp.reuters.com/article/domesticFunds/idJPnTK834789220090401

 [1日 ロイター] 米シリコン・グラフィックス(SGIC.O: 株価, 企業情報, レポート)は1日、連邦破産法11条の適用を申請した。裁判所への提出文書で明らかになった。

 同社は総資産3億9050万ドルに対し、5億2650万ドルの負債を抱えている。

 シリコン・グラフィックスの債権者には、インテル・アメリカ、キモンダ・ノースアメリカ、IBMなどが含まれている。

記事中の企業の関連情報は、各コードをダブルクリックしてご覧ください。



ほほー
LKMLでの活動に影響は出るんかな?


関連記事
linux | 【2009-04-01(Wed) 21:27:39】 | Trackback:(0) | Comments:(0)

なぜかRubyのM17Nの記事からリンクが貼られていた件について このエントリーをはてなブックマークに追加

http://gihyo.jp/dev/serial/01/ruby/0004

不思議すぎる(?_?

関連記事
文字コード | 【2009-04-01(Wed) 02:51:16】 | Trackback:(0) | Comments:(0)
前のページ
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。