[gentoo-dev] What is the status of phone/tablet support?

[Richard Yao]

I asked in #gentoo-embedded on freenode, but I would like to pose this question
to a wider auidence through the list.

What is the status of phone/tablet support? In specific, I am curious about:

* Modern hardware options (especially those without a hardware keyboard)
* Status of F/OSS drivers
* Xorg touch support (multitouch, virtual keyboards, etcetera)
* Desktop environments designed for multitouch in portage
* Graphical applications (e.g. dialer, calendar, web browser, email client)
* Reliable filesystem options for flash storage in small memory environments.

I know that the KDE project has Plasma Mobile, which gives us both a desktop
environment and many key graphical applications. However, I am not sure if much
has been done to support it in Gentoo's packaging and I would like to hear about
this:

http://www.youtube.com/watch?v=auuQA0Q8qpM

I realize that it is difficult to convey the sort of information that one wants
on an open ended topic such as this, so I will try to lead by example by talking
about filesystem options. First off, Linaro has some good summary:

https://wiki.linaro.org/Flash%20memory

Their summary consists entirely of log-based filesystems and CoW filesystems. It
omits in-place filesystems such as ext4 and XFS. In-place filesystems really
should not be appropriate for a phone or tablet because they are not designed to
gracefully recover from unclean unmounts caused by kernel panics or power loss
(e.g. dead battery, battery removal), although Android uses ext4 anyway.

A notable exception from Linaro's list that I happen to maintain in the tree is
the ZFSOnLinux driver. ZFS has many attributes that are desireable for phones,
such as easy backup through incremental send/recv (easy on bandwidth and battery
life), the ability to detect corrupt data (flash is not perfect), LZ4
compression (better throughput/latencies and less flash is need to store the
amount data) and ARC for a better cache hit rate when your working set exceeds
the amount of memory you have for cache (always true on phones).

ZFSOnLinux is currently behind other CoW filesystems in support for
phones/tablets. Upstream is gradually improving this and it should become a
competitive option in the future. The main areas that pose problems are:

1. Efficient use of minimal memory.

1a. Long held objects in SLABs cripple reclaim efficiency by preventing mostly
empty slabs from being reclaimed. On Solaris, some of the caches implement a
move callback that allows for compaction, but Linux's SLAB implementation does
not provide the option, ZoL's SLAB implementation does not implement it and it
is not clear if it is possible to defragment the things on Linux that use it
without modifications to the Linux kernel. Thankfully, nearly all of the memory
used by SLABs is in the ZIO buffers, which will be replaced with page-based
scatter-gather lists in the next release. That will go a long way to mitigating
this.

1b. mmap() double caches between the ARC and the page cache. This has been done
in OSv's ZFS driver and can be done in the ZFSOnLinux driver. It is currently
blocked on 1a as it does not make sense to implement sooner, but it will be
definitely be done.

2. 32-bit support (not an issue on 64-bit ARMv8 hardware, but ARMv8 is rare)

2a. Linux's kernel virtual memory allocator is crippled because the kernel
enters an infinite loop when it runs out of address space set aside for kernel
virtual memory. This is not a problem on 64-bit system swhere the amount set
aside exceeds the amount any single image system in existence currently has, but
it is a major problem on 32-bit. There is the further problem of a global
spinlock being used and certain accoutning functions iterating a linked list of
all virtual memory allocaitons, but this secondary has been mitigated mostly
through SLAB allocation. The main use of kernel virtual memory is to
avoid external fragmentation issues that come from allocting large buffers,
especially the SLABs that are used to minimize the number of kernel virtual
memory allocations that are done. The next release will implement scatter-gather
lists that should bypass this on the ZIO bufers while the other consumers either
have already been moved to kernel virtual memory or should be moved.

2b. There is no upstream test coverage on 32-bit and there are open issues
involving 32-bit runtime failures. The project has gradually fixed 32-bit
issues, but more work needs to be done here to make 32-bit as reliable as
64-bit. This will likely come after the solution to 2a makes 32-bit feasible
enough to subject it to regular testing.

3. Tweaks for flash storage.

3a. We will gain discard support from the Illumos community in the next release,
but the behavior of the hardware when discard is translated into the native
command needs to be studied. On SATA, discard is mapped to ATA TRIM. The design
of ATA TRIM is broken before SATA 3.1 where TRIM is an unqueued command that
introduces arbitrary lags. Consequently, continuous discard will be off by
default and the recommended way of doing discard will be to run a fstrim-like
command on the zpool. Research will be needed to determine if the continuous
discard is appropriate for NAND used in modern phones/tablets.

3b. We need to create pools with the correct alignment shift to set the flash
page size to avoid read-modify-write overhead on pages. On modern SATA/SAS hard
drives, we can read sector sizes from SMART data, but these are often wrong on
flash drives, so we rely on a list of drive identifiers. I am not sure what we
will have on phone hardware to determine the sector size.

Many of these improvements are not of exclusive benefit to phones/tablets, so we
will gain them out of work being done for traditional laptops, workstations,
servers and clusters. I expect to see the improvements avaliable from upstream
sometime in the next 12 months.

That said, I would love to hear similar descriptions of where we stand in other
areas with regard to mobile devices.