LWN: Comments on "The end of the 3.12 merge window"

The end of the 3.12 merge window

dlang — 2013-09-29T22:09:04+00:00

> This is a good change. Processes that do check return values (like PostgreSQL) will function much better under this system...

do they really work better? or is it just theory that they work better?

If overcommit is enabled, the out of memory error isn't that likely to happen when memory is allocated, or a process forks. It's going to happen when memory is used (a variable changed, etc)

but if you turn off overcommit, you either need such a ridiculously large amount of swap that your system will be essentially dead from swapping long before you hit OOM, or you end up being unable to really use all your memory because large chunks of it are reserved for the 'just in case' situation that every CoW page will get split that never happens.

The end of the 3.12 merge window

kleptog — 2013-09-29T09:51:13+00:00

This is a good change. Processes that do check return values (like PostgreSQL) will function much better under this system...

The end of the 3.12 merge window

dlang — 2013-09-26T21:39:44+00:00

OOM conditions are generally times of massive problems for apps.

remember that most systems have the sane setting of using CoW for memory, so they don't get errors when the memory is allocated, but instead sometime later when something dirties ram.

I call this the sane setting, because disabling overcommit and requiring that your system not do the CoW trick ends up wasting so much of your ram that you end up with far more failures, and the vast majority of code doesn't check for errors even in those cases.

The end of the 3.12 merge window

heijo — 2013-09-26T21:08:48+00:00

System calls suddenly starting to return ENOMEM is a critical and catastrophic ABI breakage.

Lots of things will now malfunction in random ways under OOM conditions (since, of course, syscall return values are almost never checked).

How did that crap get in?!?

The end of the 3.12 merge window

mathstuf — 2013-09-23T16:12:47+00:00

This actually makes sense since systemd is on its way to being /the/ cgroup manager. Taking logind and patching it to call your own cgroup manager (or patching the functionality back in) is probably easier than resurrecting ConsoleKit.

The end of the 3.12 merge window

kugel — 2013-09-23T07:08:18+00:00

So there goes the promised modularity of the systemd codebase. It seems the project's statements are not dependable after all.

The end of the 3.12 merge window

ABCD — 2013-09-19T13:23:33+00:00

As of systemd-205, this is no longer true. In that version, systemd-logind lost support for creating its own cgroups (which it requires to operate), instead delegating that responsibility to systemd, which already has to be able to create them for its own purposes.

The end of the 3.12 merge window

Jonno — 2013-09-19T07:45:12+00:00

> Maybe a simple replacement for logind in this scenario is possible

> You could resurrect ConsoleKit and port the patches going into systemd-logind to it.

Also, running logind does not require running, or even installing, systemd (though you can't build one without building the other). An upstart/logind or sysvinit/logind setup would require slightly more configuration than a systemd/logind setup, but really no more (but of course different) configuration compared to an upstart/ConsoleKit or sysvinit/ConsoleKit setup, so not out of reach of the distro packagers.

The end of the 3.12 merge window

mathstuf — 2013-09-19T02:17:32+00:00

> Maybe a simple replacement for logind in this scenario is possible

You could resurrect ConsoleKit and port the patches going into systemd-logind to it.

The end of the 3.12 merge window

nix — 2013-09-18T23:31:53+00:00

So... unprivileged X, as long as I rip highly stable parts of my system apart and move to systemd? Sigh, why am I not surprised. Any excuse to wedge systemd in somewhere else, and they'll take it...

Maybe a simple replacement for logind in this scenario is possible (it's only being used as a simple message-passer, after all) which doesn't require drinking all the world-encompassing systemd kool-aid.

The end of the 3.12 merge window

blackwood — 2013-09-18T08:32:03+00:00

David Herrmann is working on it, and he's also got an imo really good plan for how to solve the revoke issue for drm device nodes. See his blog at http://dvdhrm.wordpress.com/2013/08/25/sane-session-switc... for the Big Plan. Note that the rendernode stuff merged into 3.12 is part of the prep work here - we first need to untangle the drm render (which can be done by multiple users concurrently, e.g. for background gpgpu stuff) and the modeset side which needs something like revoke.

The end of the 3.12 merge window

nix — 2013-09-18T00:12:42+00:00

So X can use it then? Unprivileged X is coming?

*loud and prolonged cheers*

(even if it did have to be an ioctl())

The end of the 3.12 merge window

daniels — 2013-09-17T22:37:07+00:00

Yes, exactly. It got in because it was input-specific, rather than attempting to be generic across all fd types. This was originally known as EVIOCMUTE, but then got changed around.

The end of the 3.12 merge window

proski — 2013-09-17T21:33:23+00:00

I believe it's good for partitions on flash that need to be aligned to some large blocks. It's better to sacrifice a hundred bytes in CMOS and in RAM than to lose 256k on a system that is tight on the flash space.

The end of the 3.12 merge window

pranith — 2013-09-17T19:35:02+00:00

The reason for the code name can be found in Linus` post to G+:

https://plus.google.com/102150693225130002912/posts/9Gjr5...

The end of the 3.12 merge window

aeruder — 2013-09-17T19:05:09+00:00

Think embedded systems where you may have some small flash device with your bootloader/bootloader settings (and kernel command line) and a SD card for the root filesystem.

The end of the 3.12 merge window

nix — 2013-09-17T19:01:24+00:00

The evdev input layer has gained a new EVIOCREVOKE ioctl() command that revokes all access to a given file descriptor

i.e. revoke() for input fds, just what the X people have been asking for for ages for non-root X server support but that never got in? Did it only get in because it was an (ew) ioctl(), rather than a new syscall like the BSDs use?

The end of the 3.12 merge window

fishface60 — 2013-09-17T17:13:23+00:00

What is the use for putting the partition table in the kernel command line?
It says it saves space by not needing the mbr, but doesn't this mean that the partition table is moved somewhere else instead, since the bootloader needs to read it and generate the kernel command line anyway?