Update kernel

answered 2015-06-30 10:20:45 +0300

Philippe De Swert
7698 ●74 ●88 ●91

Oh we answered this many times already, you must have missed the answer... Sad truth is we don't have the manpower, time or specs to do so.

Also using some random drivers that might or might not work is not a surefire thing. You will often need matching firmwares and that will also not be so easy. Also those drivers aren't necessarly going to give more performance as you state (often actually less, due to manufacturers leaving stuff out, due to patent fear, trade secrets, ...). Nor are WLAN and GPU the only problematic areas. As mentioned there are still the telephony bits. And at a time we gave the open Prima driver a go, but it did not work well, code quality was (and maybe still is) bad. Not to mention the licensing in the code was very murky and problematic. It is not because some code is out in the open that you can use it..

1. And support from Qualcomm? They made a codedrop, that is not support... Actually you have to pay them huge amounts of money to have the privilege to ask them a question (without garuantee they will even look at it).
2. Support from kernel devs, well the driver for the adreno seems to have made it upstream, but that does not mean kernel developers will be helping you with your own issues on your own hardware. If you're lucky yes. Otherwise well hope for the best.
3. Get more from the hardware? That is debatable. As stated higher you might actually get less performance. Although you might gain some freedom indeed.

Moreover the kernel source is out there, it is not so hard to build it and flash it to your device, so if it is so important you can go ahead and start hacking. Or pay/bribe/feed pizza to some kernel devs do it for you. I am sure we will put in some of our free time to help out with that if it something like that happens.

We have mostly synced up the kernel with the current 3.4 stable so it is not like we are not doing any maintenance, but a complete device port is not something we have resources for, we have a tablet to make too. And then the next product and so on. It is not because something is possible it is realistic to do it. I am sure you could do this if you wanted, but how much time and effort is it going to take you? Will it be worth it?

answered 2015-06-30 10:25:24 +0300

DrYak
9624 ●93 ●134 ●128

http://www.sympato.ch/

Alternatively if the Linux kernel won't be upgraded soon, would it be possible to backport ZSwap ?

Currently the 3.4.x line of kernels only support Zram, and Zswap would have been a great reason to upgrade the kernel or at least backport it.

ZSwap works by creating a cache in memory where the pages are first compressed. Then once the cache fills up, the pages are moved from the RAM cache to actual swap space devices based on a Least Recently Used (LRU) principle.

Zram works slightly differently, it creates a RAM drive which is compressed. It is possible to use it as swap space with mkswap and swapon (Jolla phone does it, as do countless embed linux devices accross the world, like routers, etc). But for the kernel swap strategy, Zram is just that a swap device like any other. Once a Zram buffer is full there are no special behaviours, the kernel will simply move to the next available swap device (e.g.: a swap partition on a media) which will work like any other normal uncompressed device. Because of this Zram ends up working a bit like Most Recently Used (MRU) strategies - newer pages are written to the extra slower space device, while older pages sit idle on the faster ram disk.

Zram is a very good solution for device which don't have storage to spare (e.g.: embed device that have only ROM, or Jolla phone which probably wants to avoid wearing its internal flash to fast) and are limited in RAM.

Zswap is a very good solution for devices which do have storage and rely on it for swap.

• part of the pages are kept in RAM buffer, so effectively Zswap can also work as a ram compressor like Zram
• pages are written to swap from the buffer, so effective strategies like LRU can be used, instead of ending up with a MRU situation like Zram
• as compressed pages are written to device, this can help with slower devices (using an LZ4 compressor is certainly faster than lots of devices, including flash media)
• compressed pages also means less space used on the swap device: thus more potentially available memory or in case of flash media: less wear

Thus Zswap would be usefull on the Jolla when either using swap on an SD card (wear is less a problem as it is possible to buy a newer SD card and swap it) or to protect the small internal flash space (LRU and compressed, instead of MRU and raw).