プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

今日覚えた英語 このエントリーをはてなブックマークに追加

Now I am paying for my naive assumption by sitting on the ankles.

今、自分の浅はかな仮定の報いを正座でうけている
今、自分の浅はかな思い込みの報いを受けて、正座している

うーん、この熟語を人生で使う事は一度もない気がしてきたぞ




英語 | 【2011-06-10(Fri) 14:51:40】 | Trackback:(0) | Comments:(0)

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

さいきん、madvise()にいくつか追加があったのでman pageの査読をしている。
そのなかでHugh Dickinsが言った言葉

> @@ -221,8 +266,10 @@ for file access.
> .BR MADV_REMOVE ,
> .BR MADV_DONTFORK ,
> .BR MADV_DOFORK ,
> +.BR MAD_HWPOISON ,

Oh, I absolutely agree with you, MAD_HWPOISON indeed;
but Andi might prefer MADV_HWPOISON.



そこに absolutely agree するのかよ :-)

英語 | 【2010-06-22(Tue) 18:35:20】 | Trackback:(0) | Comments:(2)

[英語] Your proposal looks very promissing to me. このエントリーをはてなブックマークに追加

Your proposal looks very promissing to me.

あなたの提案はすごく有望だと思うよ。
MLで相手を褒める時に使う。メモ


英語 | 【2009-12-01(Tue) 12:12:24】 | Trackback:(0) | Comments:(4)

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


Hi Dmitry,

> > > It looks like
> > >
> > > commit 7d930bc33653d5592dc386a76a38f39c2e962344
> > > Author: Johannes Berg
> > > Date: Tue Oct 20 15:08:53 2009 +0900
> > ...
> > > is causing oops on resume:
> >
> > There is a fix for this in my tree and I'll push it to Linus
> > tonight.
>
> Ah, even better ;) Thanks David.

and can we please stop jumping the gun here and going past the subsystem
maintainers. I think this happens a little bit too much lately.

Regards

Marcel



jumping the gun でフライングの事。ここではサブシステムメンテナを飛び越えてパッチがマージされていく事に抗議している




英語 | 【2009-11-08(Sun) 14:56:46】 | Trackback:(0) | Comments:(0)

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

Hughが使っていたので調べてみた

http://www.japantimes.co.jp/shukan-st/writer/english_sports/english_sports.htm?v=022

によると、「宙に浮いている」「決まっていない」ぐらいの意味みたい。

まあ、ようするにDiscard Requestはまだまだ揉めていますよ。って事なんだけど

Hi Christoph,

(I've added Ccs, hoping for more expertise than we have in linux-mm.)

On Fri, 30 Oct 2009, Christoph Hellwig wrote:
>
> since 6a6ba83175c029c7820765bae44692266b29e67a the swap code
> unconditionally calls blkdev_issue_discard when swap clusters get freed.
> So far this was harmless because only the mtd driver has discard support
> wired up and it's pretty fast there (entirely done in-kernel).
>
> We're now adding support for real UNMAP/TRIM support for SCSI arrays and
> SSDs, and so far all the real life ones we've dealt with have too many
> performance issues to just issue the discard requests on the fly.
> Because of that unconditionally enabling this code is a bad idea, it
> really needs an option to disable it or even better just leave it
> disabled by default for now with an option to enable it.

Thanks for the info.

Yes, in practice TRIM seems a huge disappointment: is there a device on
which it is really implemented, and not more trouble than it's worth?

I'd been waiting for OCZ to get a Vertex 1.4* firmware out of Beta
before looking at swap discard again; but even then, the Linux ATA
support is still up in the air, so far as I know.

You don't mention swap's discard of the whole partition (or all
extents of the swapfile) at swapon time: do you believe that usage
is okay to retain? Is it likely on some devices to take so long,
that I ought to make it asynchronous?

Assuming that initial swap discard is good, I wonder whether just
to revert the discard of swap clusters for now: until such time as
we find devices (other than mtd) that can implement it efficiently.

If we do retain the discard of swap clusters, under something more
than an #if 0, any ideas for what I should make it conditional upon?

Something near /sys/block/sda/queue/rotational (nicely rw these days)
seems appropriate: any chance of a /sys/block/sda/queue/discard_is_useful?
I think I'd prefer that to a new option to swapon.

Or is there a sensible measurement I could make in swapfile.c: for
example, does discard of a range complete faster than write of the
same range? (But my guess is that those devices we'd want to avoid
discard on, would give erratic answers to any such test; never mind
the noise of what other I/Os are concurrent to the same device.)

Something I should almost certainly revert: at one stage I made the
non-rotational case spread its swapping evenly over the partition,
in case the device's wear-levelling was inadequate (localized).

But now I think it's better to ignore that possibility, and anchor
swapping to the start of the partition just as in the rotational case:
in the rotational case it's done to minimize seeking, in the non-
rotational case it would be to minimize encroaching upon that
initially discarded total extent.

Hugh

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




英語 | 【2009-11-02(Mon) 00:00:22】 | Trackback:(0) | Comments:(0)
前のページ 次のページ
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。