Gauging interest: -rthink patchset/.config

[ThinkRob]

For the last year or so now, I've been maintaining my own personal kernel patchset(s), one bleeding-edge (against the latest stable kernel), and one long-term stable (against the 2.6.32 branch). It's usually a pretty minimal patchset, but sometimes I pull in or backport various things that I think would make life easier.

I've been thinking about publishing both my patchset and my .config for anyone who's interested. Obviously, since this is a bit of a larger undertaking, I'd like to see what sort of interest there would be in such a project.

The plan would be to publish two sets of configs and patches, one for whatever the latest mainline kernel release is, and one for the latest of the 2.6.32 branch.

My patchset typically includes:

- grsecurity/PaX
- alternate/experimental/special-purpose I/O schedulers
- any power-saving patches (backported as necessary)
- any i915 fixes that can be backported without breakage
- the latest version of thinkpad-acpi
- misc. patches (minor fixes, precautionary security patches, etc.)

My .config typically:

- omits any drivers that don't make sense for a ThinkPad (InfiniBand, frame relay support, that sort of thing)
- compiles in things that are critical for a ThinkPad (e.g. thinkpad-acpi)
- compiles in common filesystems (since forgetting to include these in your initrd.img sucks)
- enables either voluntary or real-time preemption with CONFIG_HZ_300
- aims to maximize power savings

I would also produce two versions of the .config: one with grsecurity enabled with a fairly militant configuration, and another without it. (grsecurity/PaX offers a lot of functionality and a lot of options, so it's probably the sort of thing that you'd want to set up on your own, hence the second option.)

--

So that's what I've got in mind. I have no idea if this will be useful to anyone, but if there's sufficient interest, I'd be happy to give it a shot.

Cheers,
Rob

[dk]

I would definitely be interested in seeing your .config!

Derrick

[comps]

@ThinkRob: Not to disregard the effort made to create such patchset, but I would say it's rather too specific. Most people either use default distro-provided kernel or make their own "patchset" that suits their needs, because kernel configuration is now (2.6) a lot easier. Full patchsets are much more useful as individual series of patches that anyone can browse in and pick any favorites. Of course, that doesn't mean there won't be anyone interested in a full patchset.

In this my post, I'd like to give you at least some feedback / points to think about. Please take no offense.

- alternate/experimental/special-purpose I/O schedulers

I have tested both Con's BFS CPU scheduler and the BFQ I/O scheduler with pretty much zero gain. The BFS scheduler needs non-NO_HZ kernel with at least HZ_1000 to work as expected. BFQ have failed (on my testing machine) to schedule out a big write() syscall of a heavy-disk-I/O process and prefer other processes. It might as well be related to NO_HZ. If not, then I'd say BFS/BFQ is nothing but a placebo effect

- any i915 fixes that can be backported without breakage

I'd be careful with those. I don't know how often you plan to release your patchset, but "bleeding edge" people can simply get those fixes from the next upstream version and "long-term" people will get those from 2.6.32 maintainers. I see little gain in backporting them any sooner and some danger in doing so (I already made one kernel unbootable by backporting an "innocent" radeon typo fix).

- the latest version of thinkpad-acpi

If you are able to safely backport bleeding-edge thinkpad-acpi onto 2.6.32, then it would be nice.

- misc. patches (minor fixes, precautionary security patches, etc.)

In my "patchset", those fixes often include things that only I want, since they are really specific and not useful to most people. Things like "do not ever lock cdrom drive", "colored printk", some custom netfilter modules I wrote and so on. The kind of patches you don't want in a generic patchset. If your "misc. patches" include backported upstream fixes instead, then please ignore this paragraph.


The .config idea is, in my opinion, a lot more useful one, since there are tons of kernel-configuration newbies and those often include many things they don't need and/or forget thinkpad-specific / important things. So I can't argue with a sane "defconfig for thinkpads".

Other than that:

- enables either voluntary or real-time preemption with CONFIG_HZ_300
- aims to maximize power savings

You can either run NO_HZ kernel and have maximum power savings, or run HZ_NNNN kernel with regular ticks (without NO_HZ) and get decent response time, .. or use the RT patchset. The CONFIG_HZ_NNNN has very little meaning when NO_HZ is enabled.
So, use NO_HZ to gain better battery life, CONFIG_HZ_1000 (optionally with Con's "low latency" patches) to get better system responsiveness at the cost of battery life .. and the RT patchset to get realtime scheduling (if you really need it) at the cost of lower battery life.


There are quite a lot of patches one would like to set-up on it's own, like the PHC (undervolt) one, which REALLY makes a difference (68°C before, 56°C after - under heavy load). I myself maintain my own tp_smapi git tree outside the kernel, since making upstream hdaps.c compatible would need a lot more effort.

Using all the power-saving I can get, I'm able to last for about ~10 hours with lowest brightness and firefox-browsing via ethernet (T500, i915, 9-cell battery). The power saving includes, amongst others, things like software-ejecting the ultrabay drive, turning off wake-on-lan, using 100Mbit ethernet mode, always-spinning HDD (turns out that it's more power/latency-efficient than spinning it up each 4-5 minutes, except for only-firefox-browsing ).


I hope you'll find some of my points useful.

comps

[ThinkRob]

I have tested both Con's BFS CPU scheduler and the BFQ I/O scheduler with pretty much zero gain. The BFS scheduler needs non-NO_HZ kernel with at least HZ_1000 to work as expected. BFQ have failed (on my testing machine) to schedule out a big write() syscall of a heavy-disk-I/O process and prefer other processes. It might as well be related to NO_HZ. If not, then I'd say BFS/BFQ is nothing but a placebo effect

I wasn't referring to CPU schedulers at all. I avoid non-mainline ones, as they tend to have... quirks.

As far as IO schedulers are concerned, there are a few other options out there (such as some that have been submitted to the LKML and revised, but ultimately not included in the mainline.)

I'd be careful with those. I don't know how often you plan to release your patchset, but "bleeding edge" people can simply get those fixes from the next upstream version and "long-term" people will get those from 2.6.32 maintainers. I see little gain in backporting them any sooner and some danger in doing so (I already made one kernel unbootable by backporting an "innocent" radeon typo fix).

I am indeed careful. I backport fewer changes to my .32 branch, because 1) I consider that to be my 'stable' kernel 2) many of the changes between .32 and current mainline would require some serious, invasive changes which I have neither the expertise nor the resources to backport a) regularly and b) reliably.

The kind of patches you don't want in a generic patchset. If your "misc. patches" include backported upstream fixes instead, then please ignore this paragraph.

I don't include personal patches. Well, I do in my personal builds, but since they're already broken out and free-standing, I could simply not include them. The patches I tend to include are 1) simple but important upstream fixes that haven't (or won't) make it to .32 2) security fixes that can't/haven't/won't/aren't likely to make it to the mainline (Debian's fixes for a couple potential NULL-derefs would be an example of this.)

Patches in this category tend to be precautionary security fixes, edge-case fixes, and info. leak fixes that for whatever reason haven't made it to the mainline yet.

The .config idea is, in my opinion, a lot more useful one, since there are tons of kernel-configuration newbies and those often include many things they don't need and/or forget thinkpad-specific / important things. So I can't argue with a sane "defconfig for thinkpads".

Well I couldn't provide a safe .config for all ThinkPads. The best I could do would be a sane config for T60-era onwards, as I lack the hardware resources to produce something that "officially" supports earlier models.

The CONFIG_HZ_NNNN has very little meaning when NO_HZ is enabled.

I don't believe that's true. NO_HZ will suppress the tick when the system is idle, but when I last checked there was still a substantial amount of code that depended on the HZ options. Yes, when the next timer expiration is far enough away and the system is idle, the HZ setting doesn't matter -- but that doesn't mean that CONFIG_HZ_### is useless.

There are quite a lot of patches one would like to set-up on it's own, like the PHC (undervolt) one, which REALLY makes a difference (68°C before, 56°C after - under heavy load). I myself maintain my own tp_smapi git tree outside the kernel, since making upstream hdaps.c compatible would need a lot more effort.

I would include PHC, but due to the nature of it I'd rather it be a "do it yourself so you know what you're getting in to" sort of thing.

I hope you'll find some of my points useful.

Absolutely. This is exactly the sort of feedback I was hoping for.

[comps]

I don't believe that's true. NO_HZ will suppress the tick when the system is idle, but when I last checked there was still a substantial amount of code that depended on the HZ options. Yes, when the next timer expiration is far enough away and the system is idle, the HZ setting doesn't matter -- but that doesn't mean that CONFIG_HZ_### is useless.

...

I would include PHC, but due to the nature of it I'd rather it be a "do it yourself so you know what you're getting in to" sort of thing.

That's why I said "very little meaning", not "no meaning". There's a lot of code and formulas that use the HZ_### settings indeed. It's primary meaning is, however, supressed.

...

You can include PHC. It uses default settings (ie. no voltage changes) unless someone writes new values to the sysfs file, so it's safe by default.

[ThinkRob]

That's why I said "very little meaning", not "no meaning". There's a lot of code and formulas that use the HZ_### settings indeed. It's primary meaning is, however, supressed.

Ah. Sorry, I misunderstood.

You can include PHC. It uses default settings (ie. no voltage changes) unless someone writes new values to the sysfs file, so it's safe by default.

Oh, I know it's safe by default. I'd still omit it though as an intentional way of raising the bar. Kind of a matter of personal philosophy I guess...

[harrigan]

I would like to see the .configs and patches but I would cherry pick items of interest rather than apply a full patchset. Providing testing feedback on the items I did use would be no problem.

[ThinkRob]

I would like to see the .configs and patches but I would cherry pick items of interest rather than apply a full patchset. Providing testing feedback on the items I did use would be no problem.

Well they're broken out in my current src tree, so that's no problem. Of course some of them might not apply cleanly on their own (some of the ACPI stuff that I've done in the past comes to mind)...

I'm leaning towards at least providing a baseline .config for people, but I'm still undecided about the patches.

[harrigan]

Of course some of them might not apply cleanly on their own (some of the ACPI stuff that I've done in the past comes to mind)...

Very true. That's something I would have to deal with myself.

I'm leaning towards at least providing a baseline .config for people, but I'm still undecided about the patches.

That seems like a sensible approach to me. Provide the .config, see what kind of feedback you get, get a better feel for who your real audience is and then you can decide whether providing patches is worth it.