Workstation product kernel requirements

[Josh Boyer]

On Wed, Nov 6, 2013 at 7:53 AM, Bastien Nocera <bnocera at redhat.com> wrote:
> ----- Original Message -----
>> On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera <bnocera at redhat.com> wrote:
>> > ----- Original Message -----
>> >> Hi All,
>> >>
>> >> My apologies for sending this out so late compared to the other
>> >> product queries.  I will simply claim that I hope the current Fedora
>> >> kernel is already meeting desktop/workstation needs and my delay was
>> >> partially because of that ;).
>> >>
>> >> At any rate, the kernel team would like to know what you see as the
>> >> requirements for the Workstation product.  Thus far the discussions
>> >> with the other product groups has mostly centered around packaging
>> >> changes.  I would imagine Workstation doesn't particularly suffer from
>> >> anything in the current packaging, and could likely share a common
>> >> packaging scheme with Server for the most part.  However, if that
>> >> isn't the case please let us know what you'd like to see from a
>> >> packaging standpoint, keeping in mind we want a single main kernel
>> >> package across all 3 products as much as possible.
>> >>
>> >> On IRC, Matthias mentioned some issues around interactivity and I/O.
>> >> If there are other things like that, please speak to those as well.
>> >
>> > Is this supposed to be a wishlist, or a list of things that should carry
>>
>> No, not really a wish list.  That being said, creating a wishlist
>> isn't a bad idea.
>>
>> > on working/possible release blockers?
>>
>> Mostly I'm curious what you find lacking.  I'm not going to say we
>> personally are going to fix it with the bug backlog we already have,
>> but it's good to be aware of areas that could use change/improvement.
>
> In terms of bug fixing, as you mentioned on IRC, lowering the wakeup count
> for common kernel drivers would be very useful.

OK.  "Common" is something we need to define for the product.  I have
a fairly good idea already, but there is a lot of hardware out
there...

>> > For the former, on top of my head:
>> > - Production-ready btrfs with the ability to export those snapshots over
>> >   the network (I've asked about this before, got no answer)
>> > or,
>>
>> Yes, well, the world continues to wait for btrfs in general.  Wish
>> list item indeed.
>
> btrfs would fix our problem if we can export those snapshots over the network.
> I didn't see a way to do that.

I was implying that btrfs isn't really ready to be used in a product.
At all.  Not just snapshotting.  It still has a number of issues with
corner cases.  Josef and company are doing really good work on getting
it fixed up, but we still see a ton of reports from people using it
today.

So maybe not for the initial product, but the next one.  I can take
the export over the network idea upstream, but I want btrfs to get
more stable before they shove more features in.

>> > - directory hard link support for ext4 (probably hidden behind a mount
>> > option
>> >   with warnings and bells)
>> > - "time" changes up the directory chain when something changes (eg. if
>> > something
>> >   changes in /foo/bar/baz, a timestamp on /foo will be changed)
>> > - Export of "wake reason" when the system wakes up (rtc alarm, lid open,
>> > etc.)
>> >
>> > These would probably be necessary to implement a highly integrated backup
>> > system.
>>
>> Is there a reason thin dm provisioning isn't suitable here?  I've only
>> tangentially paid attention to it, but I thought snapshots and backups
>> were one of the motivating factors for pushing that in Fedora.
>
> Thin provisioning is probably usable, but requires a particular partitioning scheme,
> changing defaults in anaconda. It's a nice way to avoid relying on btrfs for now,
> but I don't see it as the final solution. I also don't know whether it's possible
> to export those snapshots over the network, just like for btrfs.
>
> The timestamp changes and wake reasons changes are also needed. The first one would
> help any indexer (backups, the tracker indexer, man-db, locate-db, etc.), the
> second one would be useful to allow waking up machines during the night to start
> backups.

OK.

> <snip>
>> > - an hibernation implementation that doesn't use the swap space
>> > (interactivity
>> >   sucking when there's a run-away process, or hibernation? choose...)
>>
>> Please don't make us look at hibernate.  We cry.
>
> Until all laptops ship with firmware level hibernation (like Intel Rapid Start), that's
> going to be a problem.

Is hibernation really used widely enough when compared to suspend?  In
the not distant future, Intel chips will support Connected standby
(low power idle) and make suspend mostly go away.  Hibernate is
different, but if your machine can sit in idle for 2 weeks do you
really need to write it out to disk?

>> > - memory compression enabled by default on certain classes of hardware
>> > (fast enough CPU)
>>
>> For what purpose?  Also, this is definitely magical wishlist right now.
>
> Decrease reliance on the slow swap for a lot of desktop workloads. Not sure it's
> a magical wishlist item, there are patches and some of them even got merged recently
> if I'm not mistaken:
> http://lwn.net/Articles/545244/

Yeah, I'm aware of zswap.  We have it enabled already in the kernel.
I'm not entirely convinced it will wind up being a huge performance
win though, because eventually memory pressure causes it to uncompress
the pages it has in its cache and write those out to swap.  Worth
trying I guess.

I thought your request was more for compressed memory everywhere, not
just swap related.

>> > - better documentation for waking up machines via USB (how do I wake up a
>> > machine
>> >   using a Bluetooth keyboard? How can I keep a USB socket powered to charge
>> >   a device, etc.)
>>
>> OK.  Though bluetooth would probably have to stop crashing every time
>> a device disconnected unexpectedly first...
>
> Seems pretty reliable to me with somewhat recent kernels. I've connected and
> disconnected a Bluetooth mouse a number of times to fix some UPower bugs for
> this type of device.

As usual, it depends on the device, the machine, the kernel, and the
conditions.  Things the bluetooth maintainers have access to or are
widely popular work well.  Other things don't.

>> > That's a first pass, and more than enough to keep the kernel guys busy for
>> > a little while :)
>>
>> OK, so those are all good things (well, maybe not all of them..), but
>> they're definitely more upstream issues.  Not everyone is aware of
>> this, but "Fedora kernel maintainer" usually doesn't translate to
>> "work on upstream kernel features".  In fact, days where I get to
>> write a patch for _anything_ are happy days.  Most of our time is
>> spent on bug fixing, triage, testing, etc.
>>
>> As I said above though, it's good for us to be aware of these things.
>> We can keep an eye on them, and talk to the relevant upstreams as they
>> get developed.  I just don't want anyone to get the impression that
>> we're going to solve anything rapidly.
>
> As discussed on IRC, it would be good if the Fedora kernel team could help with:
> - providing test builds for patches that are already available, this would allow
>   us to develop the necessary user-space changes (eg. the user-space OOM killer
>   would require systemd changes for example)
> - follow-up on the kernel lists about specific changes being useful for the workstation
>   use case.
> - regularly report to the fedora-desktop list with the status of those items, and
>   other bug fixes that relate to the desktop (did we get a wake-up reducing patch
>   merged upstream that's now available in our builds? that's useful information for
>   testing)
> - provide guidance on the items that don't have patches, eg. are they likely to be
>   accepted changes, which lists/persons to contact about them, maybe point at the
>   code that'd need to be changed if somebody wants to take up cooking a patch.
>
> Does that sound feasible?

I'll think about this and talk with the team.  I can envision it being
a section of "future needs/directions" or something in the monthly
kernel report we send out to upstream, so it seems doable.  My only
concern is if it becomes a big time sink.  If that starts to happen,
we'll have to adjust.  Good ideas though.

josh