November 2009

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.



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


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





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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

で、当然 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 ...



man ln しろ




まあ、ようするに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.


To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to For more info on Linux MM,
see: .
Don't email: