----- Original Message -----
On Wed, Nov 6, 2013 at 7:53 AM, Bastien Nocera
<bnocera(a)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