LWN: Comments on "The conclusion of the 3.9 merge window"

flicker-free suspend/resume on Intel

kevinm — Thu, 14 Mar 2013 00:46:41 +0000

If CLOCK_MONOTONIC in Linux actually worked according to POSIX spec, then a timer based on this clock could be used to fix this problem.

(POSIX says that CLOCK_MONOTONIC measures time elapsed since "an unspecified point in the past", and further "This point does not change after system start-up time.". On Linux however, CLOCK_MONOTONIC stops while the system is suspended, which is clearly nonconforming).

The conclusion of the 3.9 merge window

mathstuf — Sun, 10 Mar 2013 05:15:35 +0000

I thought it was arbitrary hierarchy (CPU tree != mem tree) that was going to be dropped.

The conclusion of the 3.9 merge window

meyert — Sat, 09 Mar 2013 23:04:20 +0000

Shouldn't the cgroup hierarchy support be removed in the long term? Or am I mixing this up?

The conclusion of the 3.9 merge window

Lennie — Fri, 08 Mar 2013 17:49:34 +0000

Had a quick look at dm-cache seems they actually have 3 things which can all be stored on different devices: the backing store, the cache and the meta data.

The conclusion of the 3.9 merge window

Lennie — Fri, 08 Mar 2013 17:30:44 +0000

The user unfriendliness exists to protect your data when using write-back.

It is kinda annoying, I know.

But if a normal block device would be used as a backing store there is nothing to preventing accidental use even though there might be dirty data on the cache device.

The EnhanceIO developers use some udev scripts to prevent this, I haven't looked at how they do it. I guess that could work, the EnhanceIO developers said they haven't seen any problems yet. But I can definitely see why the bcache developer made his choice.

If a cachesystem would have be integrated in the filesystem the filesystem could have something recorded which would prevent it from being mounted without the user forcing it in some way when the cache device is never coming back.

It is kinda interesting to see there are 6 ways/ideas floating around to do caching or caching related things now for the Linux kernel:
- dm-cache, now in the kernel I guess
- Facebook Flashcache
- Google bcache
- EnhanceIO was based on Flashcache I believe
- If I'm not mistake in recent kernels there is code in the VFS which keeps track of which data is hot
- btrfs developers are looking at doing something in btrfs, if I remember correctly they have expressed some interest in the VFS solution

The dm-cache, EnhanceIO and bcache have 'spoken' on the mailinglist and one even mentioned he didn't see any problem in having several implementations in the mainline kernel.

I'm not so sure Linus would even accept those patches. :-)

It is interesting and maybe sometimes seems a bit painful to see that many different efforts. They obviously all have their strengths and weaknesses of course.

flicker-free suspend/resume on Intel

njwhite — Fri, 08 Mar 2013 15:35:58 +0000

Ah, I've run into this with wpa_supplicant on Debian. Have you found a solution to it? Is there a straightforward way to get dhclient to wake up when the computer resumes?

flicker-free suspend/resume on Intel

johill — Fri, 08 Mar 2013 09:07:13 +0000

This would be easier in connman as it has DHCP built into it rather than calling out to dhclient (running as a daemon)

The conclusion of the 3.9 merge window

msnitzer — Fri, 08 Mar 2013 02:37:09 +0000

Have you benchmarked bcache vs dm-cache vs enhanceio? If so I'd love to see what you found. We have an "all-caches" branch here:
https://github.com/jthornber/linux-2.6/tree/all-caches

But we definitely need to definitely update the bcache and enhanceio code.

Also, please note that there are some dm-cache fixes that will likely be sent to Linus for 3.9-rc2 that Alasdair (DM maintainer) has staged here: http://people.redhat.com/agk/patches/linux/editing/series...

The conclusion of the 3.9 merge window

msnitzer — Fri, 08 Mar 2013 02:27:01 +0000

dm-cache has no relation to the original dm-cache (or flashcache).

flicker-free suspend/resume on Intel

mgedmin — Fri, 08 Mar 2013 00:56:05 +0000

Somewhat tangentially there's a very interesting article about DHCP tricks that MacOS X does to reconnect faster.

I'd love to see Network Manager pick up something from that.

Instead, currently when I suspend a laptop via ssh -t foo sudo pm-suspend, I get to enjoy a lapsed DHCP lease on resume, for a few hours. According to strace that's because dhcpd expiration timer (i.e. select() with a timeout) simply stops while the laptop is suspended. Connection still works, but the wifi router doesn't resolve the laptop's hostname until dhcpd finally wakes up.

flicker-free suspend/resume on Intel

johill — Fri, 08 Mar 2013 00:10:46 +0000

Yeah, that's what I suggested first (and indeed Dan has now opened a bug for to implement it in NM), however it is possible to break it down further like I was trying to describe later:

1) scan the last channel
2) scan the known channels for the last SSID
3) scan all (remaining) channels

The intermediate step only makes sense if those known channels are a relatively small subset of all channels, but with typical installations they will be. In fact, for many networks like your home network 1) and 2) will be exactly the same because you only have a single AP, but for typical enterprise networks 2) will still be better than 3).

flicker-free suspend/resume on Intel

dlang — Thu, 07 Mar 2013 23:25:35 +0000

well, you should first check the channel you were last using, and then do the normal scan you would do if someone just gave the SSID and told you to connect to it.

flicker-free suspend/resume on Intel

johill — Thu, 07 Mar 2013 20:39:27 +0000

Well, yes. Although you could scan the channels in the right order, i.e. the ones that you'd expect the same network (SSID) on first. Say your corporate installation -- it's probably only going to use a handful of channels (1,6,11,36,149 or so), so if you know from "experience" that (almost) all of the APs for the network are there, you can scan those first.

But ultimately you're right, in the general case you have to scan all channels and that simply takes a while. It shouldn't be more than a few seconds since you're not connected; here it takes ~3.5 seconds to scan all the channels my card supports, but I know that it can be (much) slower depending on the device.

flicker-free suspend/resume on Intel

raven667 — Thu, 07 Mar 2013 17:18:40 +0000

It's also not as if this kind of problem is unique to Linux or NetworkManager, I experience very similar behavior on my MacOSX laptop when resuming from suspend, so this is a common problem with wireless. The stated solution probably won't speed up connection when changing location but keeping the same SSID as you will likely be connecting to a different AP on a different channel and it'll have to scan anyway.

flicker-free suspend/resume on Intel

johill — Thu, 07 Mar 2013 14:03:01 +0000

The "immediately" online behaviour isn't really immediate, you will typically have been disconnected from the AP. In fact, this disconnection is now going to be enforced for 3.10 because the other behaviour doesn't gain a whole lot (you still need to reconnect etc.) and trying to keep the connection causes a huge amount of issues, particularly with USB hardware (that can be unplugged while suspended.)

The "ultrabook" behaviour you refer to can be achieved with WoWLAN (http://wireless.kernel.org/en/users/Documentation/WoWLAN) and network scanning offload (while in suspend), but this doesn't exist in Linux yet.

However, a much easier solution could be implemented in NetworkManager: instead of scanning on all channels when resuming, it could scan just the channel that it was previously connected on. If that finds the previously connected AP, it would be able to reconnect almost immediately (delay of less than half a second), vs. a full scan that can take up to 10-15 seconds. This should be a fairly simple NetworkManager change.

flicker-free suspend/resume on Intel

sebas — Thu, 07 Mar 2013 13:12:45 +0000

Thanks all for the answers, that's exactly what I wanted to know.

Looking forward to flicker-free suspend/resume. Because I do that approximately a 100 times more often than rebooting, so not sure why everybody cares so much about flicker-free boot, with suspend states working stable and fast.I also hope to get a nice speedup from this, as the vt switch takes a long time here and is quite blocking.

Now if I only could convince networkmanager to not drop the wifi connection purposefully, on suspend/resume, because that's apparently not necessary anymore with this nice ultrabook hardware. Using ifup/ifdown, it does not and is immediately online. Did anybody try that?

"cache drives"

tialaramex — Thu, 07 Mar 2013 11:25:10 +0000

They spontaneously die to firmware glitches sometimes. This is unusual for a hard drive (never had any of my rotating rust do this in 20+ years), but you get used to it after a while. The media isn't actually damaged, just the firmware has stopped talking to you. If removed and re-inserted they will typically wake up and suddenly they're OK again until next time.

"cache drives"

Tobu — Thu, 07 Mar 2013 11:09:10 +0000

The caching is in their windows software, the SSD has no visibility on the HDD.

The conclusion of the 3.9 merge window

ebirdie — Thu, 07 Mar 2013 08:05:08 +0000

Thank you for the insightfull view. I have had bookmark on Bcache and an itch to try it when circumstances allow. Now that I'm aware of dm-cache I think I'll choose ease of use over topnotch performance.

The conclusion of the 3.9 merge window

ovitters — Wed, 06 Mar 2013 22:04:24 +0000

If the module is added to the kernel the porting will be done for you. Plus the various kernel versions automatically will either have or won't have that parameter.

Or in other words: pretty well known that there is no stability guarantee and the developers prefer to include your module/driver in the kernel. Seems that this often also gets you a good review (thus better quality).

"cache drives"

ntl — Wed, 06 Mar 2013 18:30:01 +0000

Yeah, I suspected something like this. So the drive exposes only half of its advertised capacity to the host. Assuming the touted "intelligent caching algorithms" are implemented in the drive and not the Windows-only software that OCZ provides, maybe it would compare favorably in a dm-cache configuration to conventional SSDs. Maybe not.

Anyway, the drives in the link seem to be EOL.

"cache drives"

Tobu — Wed, 06 Mar 2013 18:23:29 +0000

The small print on that page says it has 50% over-provisioning, so not visible outside of the SSD firmware. That must be there to compensate for the dataplex caching driver doing something not SSD-friendly, like heavy in-place rewriting (which would otherwise prevent the FTL from doing its work refreshing cells and spreading writes). bcache at least only writes whole erase blocks (1MB default bucket size), so it doesn't need that kind of overprovisioning.

"cache drives"

k3ninho — Wed, 06 Mar 2013 18:02:12 +0000

>it's only 32GB when mounted (the rest being cache)
The rest is intended to be used as the NAND cells wear out. The device has twice as much silicon as it needs so that it can be useful for longer, given the high read-erase patterns of scratch caches. The rest is not cache.

K3n.

The conclusion of the 3.9 merge window

marduk — Wed, 06 Mar 2013 18:02:08 +0000

>> The hlist_for_each_entry() iterator has lost the unused "pos" parameter.

Unused parameters are undesirable.

>Yet another nightmare for out-of-tree modules that aim at supporting multiple kernel versions. sigh...

Out-of-tree modules are undesirable.

"cache drives"

mathstuf — Wed, 06 Mar 2013 17:07:57 +0000

Half of the drive is purely for cache. It's 64GB, but it's only 32GB when mounted (the rest being cache). There's no device for the "other half". I'd like to use that part of the drive in dm-cache, not the part I can use.

The conclusion of the 3.9 merge window

Tobu — Wed, 06 Mar 2013 14:48:05 +0000

It seems to be the fastest of the lot, and an earlier version is in use at Google. Currently the maintainer is spoon-feeding some BIO and AIO rework through maintainer reviews, and I have no idea how much of the supporting infrastructure is left to merge at this point. It's not terribly user-friendly at the moment: no dm target that would allow in-place migration, and you have to stick to a maintainer tree for continued data access (even though a pass-through shim would be sufficient for non-writeback uses).

The conclusion of the 3.9 merge window

ebirdie — Wed, 06 Mar 2013 13:48:21 +0000

And what about Bcache? I haven't seen news where this is aiming to, but according to its git-repo it seems to get development.

http://bcache.evilpiepirate.org/
https://lwn.net/Articles/501632/

>Bcache is a Linux kernel block layer cache. It allows one or more fast disk drives such as flash-based solid state drives (SSDs) to act as a cache for one or more slower hard disk drives.

The conclusion of the 3.9 merge window

Tobu — Wed, 06 Mar 2013 12:33:15 +0000

I think "dm-cache" is more similar to "dm-cache", first posted to LKML in 2006. Both are dm targets with pluggable tiering policies. EnhanceIO has some older dm-cache code by way of Flashcache, but it doesn't have the pluggable policies (I don't know if Flashcache slashed it or if there was some convergent evolution later).

flicker-free suspend/resume on Intel

blackwood — Wed, 06 Mar 2013 11:47:25 +0000

Getting fastboot merged is a long road, we've pulled in preparatory infrastructure since 3.7. Currently I'm optimistic that 3.10 will have something which can actually avoid the initial modeset in some configurations. But there are still a lot of loose pieces to nail down.

flicker-free suspend/resume on Intel

blackwood — Wed, 06 Mar 2013 11:44:37 +0000

Nope, missed the 3.9 cycle. Originally I've merged the core pm/fbdev patches for 3.9, but due to too much config madness and broken compilations I've taken them out again. The drm/i915 part itself wasn't ready in time, we still have outstanding issues. Should all land in 3.10.

The conclusion of the 3.9 merge window

renox — Wed, 06 Mar 2013 08:43:11 +0000

>> The hlist_for_each_entry() iterator has lost the unused "pos" parameter.
>Yet another nightmare for out-of-tree modules that aim at supporting multiple kernel versions. sigh...

And a perfect example why the kernel doesn't keep a stable internal ABI: otherwise you have to keep unused parameters aka bloat.

The conclusion of the 3.9 merge window

bergwolf — Wed, 06 Mar 2013 06:08:58 +0000

> The hlist_for_each_entry() iterator has lost the unused "pos" parameter.

Yet another nightmare for out-of-tree modules that aim at supporting multiple kernel versions. sigh...

The conclusion of the 3.9 merge window

bergwolf — Wed, 06 Mar 2013 06:03:31 +0000

> The device manager has gained support for a new "dm-cache" target that is able to use a fast drive (like a solid-state device) as a cache in front of slower storage devices.

What about the EnhanceIO driver that is aiming at 3.10 merge window? I assume that they are similar code accomplishing similar job, no?

http://lwn.net/Articles/538435/

"cache drives"

drdabbles — Wed, 06 Mar 2013 05:33:18 +0000

I've used many of them in many situations. They are just as good as any other. Turn on TRIM/DISCARD on a recent Intel 320 SSD and the drive will die due to a "known issue".

"cache drives"

drag — Wed, 06 Mar 2013 03:03:33 +0000

Ewww... OCZ drives are bad news from what I am told.

flicker-free suspend/resume on Intel

Tobu — Wed, 06 Mar 2013 01:37:12 +0000

Also, here is airlied's pull request. It doesn't name fastboot, but does give a shootout to “the worst news site ever”, the one I've just linked to :P

flicker-free suspend/resume on Intel

Tobu — Wed, 06 Mar 2013 01:30:44 +0000

I don't use it myself, but Phoronix mentioned that this merge has part of intel's "fastboot" work, which seems to be about reusing bios-allocated frame buffers.

flicker-free suspend/resume on Intel

neilbrown — Wed, 06 Mar 2013 01:26:44 +0000

Well if you look in kernel/power/suspend.c, in suspend_prepare(), you can see an unconditional call to pm_prepare_console(), and in kernel/power/console.c pm_prepare_console() always calls vt_move_to_console(SUSPEND_CONSOLE, 1), where
#define SUSPEND_CONSOLE (MAX_NR_CONSOLES-1)

This will always switch console unless disable_vt_switch is set, and that only gets set by a call to pm_set_vt_switch(0).

This is only called by drivers/video/geode/gxfb_core.c and drivers/video/geode/gxfb_core.c, which defaults it to 0 unless it is set by a module parameter:

module_param(vt_switch, int, 0);
MODULE_PARM_DESC(vt_switch, "enable VT switch during suspend/resume");

So it looks like, with 3.9-rc1, you always get a vt switch at suspend/resume unless you have a GEODE video controller.

(note to self: I really should use that pm_set_vt_switch() call for my omap3 display on the GTA04 instead of commenting out the call to pm_prepare_console())

flicker-free suspend/resume on Intel

marduk — Wed, 06 Mar 2013 00:42:40 +0000

It might be in 3.9-rc1 already. I didn't see any vt switching when resuming from suspend (but I never noticed it before either)

flicker-free suspend/resume on Intel

sebas — Tue, 05 Mar 2013 23:23:22 +0000

I've read that it was planned that flicker-free suspend and resume (i.e. no vt switching for S3) for the Intel KMS driver was planned for this release. Short of going through huge git log, does anybody know off-hand if this change-set made it in?