Workstation product kernel requirements

[Bastien Nocera]

----- Original Message -----
> On Wed, Nov 6, 2013 at 7:53 AM, Bastien Nocera <bnocera at redhat.com> wrote:
<snip>
> >> 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...

I'm thinking working with graphics driver and gnome-shell developers, to reduce
the wake up count for Intel graphics. Maybe iwlwifi and audio drivers as well.

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

Sure.

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

That's what's coming, there's also firmware based hibernation, but we have thousand
or even millions of machines that ship that can't use that, but could suspend
if some users/developers didn't disable swap altogether because of poor performance when
there are run-away processes, swapping at all made hibernation impossible because of
a lack of space in the swap partition.

Anaconda could create a "swap" type partition that would never actually be used for
swapping memory, just for hibernation.

The current way it's done makes it utterly unreliable and causes bad side-effects.

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

I was actually thinking of zram (né compcache), not zswap.

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

When the devices use standard protocols, I have a hard time believing that.

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

Cool.

Cheers