Innovation versus MaintenanceA Linux on ARM Dilemma

Christian “kiko” Reiskiko@linaro.org

Linaro Connect Hong Kong Q2 2012

On Wed, Mar 30, 2011 at 6:31 PM, Nicolas Pitre wrote:>> But x86 is peanuts. Really.

Is x86 really peanuts?

● Many in-kernel features– ACPI

– User-Mode Linux, KVM, Xen

– vDSO

– Suspend, resume, hibernate, cpufreq, cpuidle

– perf, kprobes, uprobes

– i386 to i7 to Medfield ● 25+ years of hardware

The x86 Platform

● Architecturally, x86 is pretty standardized:– Boot interface

– PCI (including bus discoverability)

– BIOS

– VESA

– Northbridge & Southbridge

– Little-Endian

● Even x86 SoCs are quite similar to each other

The ARM Platform

● We do have some standards. However..

● ARM doesn't specify complete systems

Instead, chip makers do

● ARM's ecosystem has inherent variation– One one side lies madness

– On the other trivialization

– Establishing competitive advantage

is not simple

● So why does Linus care about this?

LOC per architecture in Linux 3.4

arm

powerpc

mips

x86

m68k

sparc

sh

blackfin

ia64

cris

s390

alpha

0 100000 200000 300000 400000 500000 600000

● 486,429 LOC in arch/arm this month● But how did we get here?

Is It All Nokia's Doing?

● 2005: Nokia releases the 770 on kernel 2.6.12

● Support for the TI OMAP became a big deal● OEM interest in Linux spurred upstreaming

Why upstreaming benefits OEMs

● Looking at it from their perspective:

1. A simpler software enablement story

2. The long-term ability to upgrade

3. Long-tail innovation

● A standard kernel can make up for the absence of a complete platform– However, it's like eating healthy food..

They asked for it!

● SoC vendors and software integrators got the message

● Major effort from 2008 onwards to upstream

● Mixed functional results

– Many platforms have some support upstream

– For most of them, support is partial at best

● However, led to a very important change

2.6.02.6.2

2.6.42.6.6

2.6.82.6.10

2.6.122.6.14

2.6.162.6.18

2.6.202.6.22

2.6.242.6.26

2.6.282.6.30

2.6.322.6.34

2.6.362.6.38

0

50000

100000

150000

200000

250000

300000

350000

MIPSx86ARM

2.6.24: i386 & x86_64 consolidation

2.6.27: defconfig and marvell madness

2.6.35: defconfig genocide

Lines changed per architecturefor each kernel > 2.6.0

Linaro Founded (2010)

2.6.02.6.2

2.6.42.6.6

2.6.82.6.10

2.6.122.6.14

2.6.162.6.18

2.6.202.6.22

2.6.242.6.26

2.6.282.6.30

2.6.322.6.34

2.6.362.6.38

0

50000

100000

150000

200000

250000

300000

350000

MIPSx86ARM

Our collectivekarma!

Lines changed per architecturefor each kernel > 2.6.0

Linaro Founded (2010)

Victims of our own success!

● So Linus doesn't like big diffstats? Not really..● 3.4: 11086 files changed, 576155 insertions(+), 358368

deletions(-)

● Linus is concerned with poor design– Both on software and hardware platform level

● Certainly, the kernel wasn't designed to accommodate SoC variation– We know excessive variation is waste

● However, the answer isn't to reject variability– We should understand and plan for it!

2.6.02.6.2

2.6.42.6.6

2.6.82.6.10

2.6.122.6.14

2.6.162.6.18

2.6.202.6.22

2.6.242.6.26

2.6.282.6.30

2.6.322.6.34

2.6.362.6.38

0

10

20

30

40

50

60

70

80

plat-*mach-*

ARM platform and machine directoriesMODIFIED for each kernel > 2.6.0

Linaro Founded

arm-soc established

Innovation vs. Maintenence

● Our ecosystem has a rich inherent diversity● This diversity is our strength

– Each company developing new approaches to power, performance and price

● Learn from upstream's design concerns● Unchecked, this innovation is unsustainable

– We need to keep the platform healthy

– We need to do it together

● We need good abstractions; let's build them!

Interlude:

Have you ever submitted a patch to the Linux Kernel?

What Maintainers Care Aboutdiff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.cindex dba4c1d..e2b2bb6 100644--- a/arch/arm/common/clkdev.c+++ b/arch/arm/common/clkdev.c@@ -53,12 +53,13 @@ static struct clk *clk_find(const char *dev_id, const char *con_id) continue; match += 1; }- if (match == 0)- continue; if (match > best) { clk = p->clk;- best = match;+ if (match != 3)+ best = match;+ else+ break; } } return clk;

What Maintainers Care About

Maintainability beats everything else!

● Fact #1: Maintainers don't test your code– They couldn't, even if they wanted to!

● Fact #2: What gets you in trouble is breaking x86!

● Fact #3: The code needs to look good

● When submitting code upstream, you may be worrying about the wrong things.

● Kernel Upstreaming 101 at 10am today!

End of Interlude

It's time we took wider ownership of the Linux

software platform

Tools for Ownership

● Figure out what needs to change to accomodate YOUR new design– Nobody else will do it for you

● Relevant areas:

1. Enablement

2. Optimization

3. Ecosystem

● This week's Connect is a great place to start

1. Enablement

● Think about upstreaming early● Get platform enablement right the first time

– Device Tree

– Pincontrol, regulators, common clock, dma-buf

– Power management frameworks● cpuidle, cpufreq, runtime PM, device PM

● Don't miss Monday's training sessions in Fountain– Follow Deepak there

2. Optimization

● Optimize, but remember the upstream context!● Power management

– big.LITTLE Switcher and MP

● v8 and the future of the architecture● System-wide performance

– Zero-copy for GPU, CPU

● Code-level optimization– The Linaro toolchain

– NEON in-kernel – and where else?

3. Ecosystem

● The boot architecture– UEFI, ACPI and other evils

● Upgrades, enablement and the LTS Kernel● Platforms

– Android

– Ubuntu

– And beyond

● Validation and Continuous Integration

Welcome

● Thank you for making the time to come● Connect is not for innocent bystanders

– We expect YOU to help define the future

● I love this event, and I hope you will too