Workstation product kernel requirements

[Bastien Nocera]

----- 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.

> > 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.

> > - 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.

<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.

> > - 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/

> > - 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.

<snip>
> > 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?

Cheers