[dm-devel] [PATCH] announcing the dm-update target

[David Anderson]

In our ecosystem, the OTA generation and on-device application process
has evolved continually, in every release, for over 10 years now. So
we think it's unlikely that we'll stop making improvements to it. Our
current roadmap has other changes in the pipeline too. It's not just
us trying to eek out diminishing returns. Other parts of the system
change around us, and the OTA system needs to adapt.

The performance penalty is something we've been working on, and have
improved a lot since our first iteration. We're currently
experimenting with io_uring as well.

Best,

-David

On Tue, Nov 23, 2021 at 3:17 PM Alasdair G Kergon <agk at redhat.com> wrote:
>
> On Tue, Nov 23, 2021 at 02:27:18PM -0800, Akilesh Kailash wrote:
> > On Tue, Nov 23, 2021 at 1:03 PM Mikulas Patocka <mpatocka at redhat.com> wrote:
> > Older devices do not get new kernel features, only LTS updates. On the
> > other hand, by having
> > it in user-space, we have more control by adding in new features. For
> > ex: On Android S, we
> > introduced the first version of Android COW format. Now in Android T,
> > we plan to support
> > new features by having XOR compression (which saves more space).
>
> While you are developing this, sure, you're finding new ways that
> make significant space savings and want to roll them out easily
> and the userspace approach helps you to do that.
>
> But the law of diminishing returns will eventually kick in, where you
> have reached a format that provides "good enough" space savings and then
> reducing the runtime performance penalty will become the overriding
> concern and that'll point back to an in-kernel solution.
>
> So that's the end point I think we are aiming for here.  Combining the
> requirements to find a sweet spot between space saving and performance.
>
> By then, the ability still to make a tweak that saves a tiny bit more
> space isn't going to be worth paying an ongoing performance penalty
> for.  (And there could still be some sort of ebpf-style option.)
>
> Alasdair
>