Preempt vs lowlatency kernel flavours summary

[Tim Gardner]

Alessio Igor Bogani wrote:
> Hi All,
> 
> I want summarize the differences between -preempt and -lowlatency
> (http://kernel.ubuntu.com/~abogani/) kernel flavour.
> Both use the same -generic source code and differs only for kernel
> configuration.
> 
> Preempt kernel flavour set CONFIG_HZ=1000 (CONFIG_HZ=100 on amd64
> -generic) and CONFIG_PREEMPT=y (CONFIG_PREEMPT_VOLUNTARY=y on amd64
> -generic).
> 
> Lowlatency kernel flavour contain preempt config changes (1000HZ and
> PREEMPT=y) but also add these:
> 
> *) Is Built against i386 too: why we don't support 32bit(*) systems too?
> 

My ultimate goal is to whittle 32 bit support down to _one_ non-pae
flavour for the headless non-PAE server crowd (VIA and Geode). If not
for compatibility issues with some user space binary blobs (flash and
skype come to mind) I'd have already done it. I've limited resources and
a lot to get done, so legacy 32 bit support just isn't very interesting.

I've have had some hallway conversations about a 64 bit kernel with a 32
bit user space, but thats not gonna happen for Lucid.

> *) CONFIG_NO_HZ turned off
> Tickless is very important feature for reduce power consumption but is
> also increase latency a lot. We can incur in high latencies every
> times an event happens after a sufficient long time (it is a really
> short) with cpu in idle state. So if you configure your system to be
> very "ready" you could obtain the worst results.
> We, -rt kernel users, turn it off by default with a simple patch since
> Hardy (which could improve -generic kernel as well).
> 

With an HPET latency ought to be unaffected by CONFIG_NO_HZ. I suggest
that you use 'idle=halt' to avoid C4 to C0 transition times.

> *) CONFIG_FTRACE turned off
> Once some months ago Ftrace caused performance regression (one time at
> least) Moreover, as far as I know, no one user have ever requested
> ftrace available in the Ubuntu kernel so I should prefer turn it off
> (-1 of things that could break).
> 

The ftrace guys have said that even micro-benchmarks cannot detect a
difference in performance on a modern CPU. Besides, we use ftrace for
boot tracking of ureadahead data.

> *) CONFIG_SLAB turned on (instead of CONFIG_SLUB)
> SLUB was born for achieve better results in memory management in
> multi-core environment with a huge quantity of memory.
> It work better than SLAB but is slower and require more cpu. So if you
> want achieve better latency you should use SLUB for high-end systems
> and SLAB for normal systems (desktop/laptop). I suspect that the last
> ones are our target. :-)
> 

I'm gonna drag my feet on this one. Does the micro-benefit of SLAB
justify the cost of supporting 2 memory allocators? I prefer to choose
the upstream default when possible.

> *) CONFIG_TREE_PREEMPT_RCU=y
> On -rt it is heavily used without sort of problem.
> 

Does this make sense yet given that the current max number of CPUs is
only 64 ?

> Personally I would want see these changes applied because, in some
> cases, we could achieve enough good results for hope to replace -rt
> kernel for most common uses.
> 
> (*) I don't checked PAE because I never had a i386 machine with more than 4GB.
> 
> Ciao,
> Alessio
> 
> P.s.
> Some background:
> https://lists.ubuntu.com/archives/kernel-team/2010-January/008385.html
> https://lists.ubuntu.com/archives/kernel-team/2010-January/008570.html

rtg
-- 
Tim Gardner tim.gardner at canonical.com