ついったーはたまに素晴らしい芸術を生み出すよな
以下、yuguiさん（Rubyのリリースマネージャー）がつくったコミッター一覧をみた人々からの一言

http://twitter.com/yukihiro_matz/statuses/5474499333

@yukihiro_matz もうコミット権とりあげられたんだっけ？ RT: @n0kada: matzがいないw RT @yugui: @yugui/ruby-committers - the list of Ruby committers

http://enterprise.watch.impress.co.jp/docs/news/20091105_326498.html

タイトルだけ見て、すごくワクワクしながら開いたのに肩透かし。Redhatが富士通用に用意した基幹サービスに遅まきながら参画するよ。としか言ってない。日立ならではの魅力がなさ過ぎるのではないか。

日立さん、技術はすごいけど、ビジネスは今ひとつなんだよなぁ。不思議。

Balbirがcgroupsのユーザランドサポートの拡充のためにマウントポイントを固定したいと言い出した。
（いままではAdminが好きな場所にマウントすればよい、というスタンスだった）

Hi, All,

We've been having a discussion as to what would be the right place to
mount the cgroup filesystem. Jan has been proactively looking into
this. The FHS has no recommendation since cgroup filesystem came in
much later.

The options are

1. /dev/cgroup
2. /cgroup
3. Some place under /sys

The problem with (2) is that it is quite non-standard and pollutes the
root directory. (3) requires some basic support to create a directory
for cgroup under /sys. (1) seems the most obvious choice since cpusets
were mounted under /dev/cpuset, but /dev is controlled by udev.

Given the three choices or any other suggestions, is there a general
preference as to where we can mount it? The goal is to standardize
the mount point (if possible).

BTW, the mounting is expected to be done using cgconfigparser present
in libcgroup.


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

で、当然 bikeshed がはじまるわけだ。
さんざん、みんなが好き勝手いったあとに、Alan Coxが出てきて一言

> If you do, then while I DETEST the extra typing, I think
> /sys/kernel/cgroup makes most sense, since that's where you find
> debugfs and securityfs.

And for everyone else

man ln

We have the technology ...

Alan

ほかの皆（タイプ数が短いほうがいいとか言っている人たち）へ

man ln しろ

テクノロジー使え

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