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.
Thanks for your time.
josh
----- 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 on working/possible release blockers?
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, - 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.
- User-space helper for the OOM killer (http://lwn.net/Articles/552789/) - Whatever is necessary to implement "LinuxApps" containers (overlayfs would be nice for example: http://lwn.net/Articles/542707/) - an hibernation implementation that doesn't use the swap space (interactivity sucking when there's a run-away process, or hibernation? choose...) - memory compression enabled by default on certain classes of hardware (fast enough CPU) - 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.) - USB "Gadget" support (using a machine as a WWAN modem, MTP device, or hard disk) for another machine.
That's a first pass, and more than enough to keep the kernel guys busy for a little while :)
Cheers
On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera bnocera@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.
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.
- 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.
- User-space helper for the OOM killer (http://lwn.net/Articles/552789/)
Will review.
- Whatever is necessary to implement "LinuxApps" containers (overlayfs would be nice for example: http://lwn.net/Articles/542707/)
overlayfs is something multiple people want, yeah.
- 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.
- memory compression enabled by default on certain classes of hardware (fast enough CPU)
For what purpose? Also, this is definitely magical wishlist right now.
- 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...
- USB "Gadget" support (using a machine as a WWAN modem, MTP device, or hard disk) for another machine.
For what use case?
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.
josh
- USB "Gadget" support (using a machine as a WWAN modem, MTP device, or hard disk) for another machine.
For what use case?
This is something we're interested in on the ARM dev board use case (eth over usb, serial etc) as well, and possibly tablet devices although while I'm personally not particular interested in that use case I'm sure others will be. I've got it on my todo list to look at but it's not yet high up there yet. Happy to help where I can as cycles come up if its useful for others as well.
Peter
----- Original Message -----
- USB "Gadget" support (using a machine as a WWAN modem, MTP device, or
hard disk) for another machine.
For what use case?
This is something we're interested in on the ARM dev board use case (eth over usb, serial etc) as well, and possibly tablet devices although while I'm personally not particular interested in that use case I'm sure others will be. I've got it on my todo list to look at but it's not yet high up there yet. Happy to help where I can as cycles come up if its useful for others as well.
adbd support for machines that support it (are there Intel machines with support for that?), "music player" support for smaller devices (so I could plug a laptop, or tablet in a set-top box and see a sorted music collection), and installation migration for the hard disk support.
This wouldn't all be kernel code (as the recent discussion around the MTP support from Android shows), but it'd be a necessary building block.
----- Original Message -----
On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
<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.
Seems a great shame that we (Fedora) don't have the same kind of influence on upstream for the kernel as we (the desktop guys) have on GNOME or some lower-level plumbing parts.
It seems to me that it would be great if people with a better knowledge of those areas in the kernel could drive the development of the features we need for the workstation product. A number of people on the desktop team already contribute to the kernel, but we don't really have people who can drive contributions from, say, the VFS, filesystems or merging currently unmergeable features (a number of Android kernel patches would be useful to us, as seen in my original mail) in the kernel.
Keep up the good work handling our downstream bugs and consider this a mandate to ask for more headcount :)
Cheers
On Wed, Nov 6, 2013 at 5:39 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
<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.
Seems a great shame that we (Fedora) don't have the same kind of influence on upstream for the kernel as we (the desktop guys) have on GNOME or some lower-level plumbing parts.
We do have influence to a degree, but it's in areas other than new feature/code development. Dave is doing awesome things with Trinity and Coverity. Justin is working really hard on automated testing and QA. Though yes, we'd really like to start doing more upstream work.
It seems to me that it would be great if people with a better knowledge of those areas in the kernel could drive the development of the features we need for the workstation product. A number of people on the desktop team already contribute to the kernel, but we don't really have people who can drive contributions from, say, the VFS, filesystems or merging currently unmergeable features (a number of Android kernel patches would be useful to us, as seen in my original mail) in the kernel.
Keep up the good work handling our downstream bugs and consider this a mandate to ask for more headcount :)
Not a bad idea. I have a new manager now. I'll see if I can sucker^Wconvince him we have a need ;)
josh
On Wed, 2013-11-06 at 08:51 -0500, Josh Boyer wrote:
We do have influence to a degree, but it's in areas other than new feature/code development. Dave is doing awesome things with Trinity and Coverity. Justin is working really hard on automated testing and QA. Though yes, we'd really like to start doing more upstream work.
Havin a set of automated test cases that cover areas of kernel functionality that are of interest to desktop-y uses would be awesome.
As for wishlist items: Having a union fs in the kernel would really help with application sandboxing. But I don't think that is an item for the Fedora kernel team...
----- Original Message -----
On Wed, 2013-11-06 at 08:51 -0500, Josh Boyer wrote:
We do have influence to a degree, but it's in areas other than new feature/code development. Dave is doing awesome things with Trinity and Coverity. Justin is working really hard on automated testing and QA. Though yes, we'd really like to start doing more upstream work.
Havin a set of automated test cases that cover areas of kernel functionality that are of interest to desktop-y uses would be awesome.
As for wishlist items: Having a union fs in the kernel would really help with application sandboxing. But I don't think that is an item for the Fedora kernel team...
That was the overlayfs mentioned in my original reply.
----- Original Message -----
On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera bnocera@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
- 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.
The generic way of exporting block and block snapshots over the network in the enterprise storage/virt arena is quite often NBD. For backups a lot of enterprise platforms use NDMP. There's NBD support in the kernel with a number of user space tools and services already in Fedora. Not sure whether it needs fs level support or what you want to do with it but they might help.
Peter
On Wed, Nov 6, 2013 at 7:53 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera bnocera@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
----- Original Message -----
On Wed, Nov 6, 2013 at 7:53 AM, Bastien Nocera bnocera@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 6 Nov 2013 09:03:57 -0500 Josh Boyer jwboyer-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org wrote:
- 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?
There might be a chicken-and-egg problem here. I, for one, don't use hibernate because it is unreliable. If it were more reliable, I would be very interested in using it, because I use full-disk crypto and it's the only way (I know of) to get a suspend-like state without my keys still in memory.
An alternative solution to this particular problem, that would actually meet my better, would be some mechanism whereby the kernel scrubs LUKS keys on suspend and re-prompts on wakeup before resuming the universe.
- - Michael
- -- Michael Ekstrand — http://elehack.net/
desktop@lists.fedoraproject.org