lkml.org 
[lkml]   [2008]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectReading EeePC900 battery info causes stalls when using SLUB (was Re: How how latent should non-preemptive scheduling be?)
Sitsofe Wheeler wrote:
> I have an EeePC 900 (Intel Celeron 900Mhz) and it seems to be
> skipping while playing sound through various desktop apps with a
> 2.6.27rc6 kernel. It is running off an SD card which really shows up

After weeks of head scratching as to why these latencies didn't occur
using the xandros 2.6.21.4 kernel (but keeping the same userspace) when
my own kernels would always show this problem I finally found the answer
after reading
http://tservice.net.ru/~s0mbre/blog/devel/other/2008_10_01 on kernel
planet - SLUB can cause regressions compared to SLAB. Switching from
SLUB to SLAB made the problem more or less disappear (which I guess
makes sense given the large number of kmem_* calls that are made when
reading the battery).

My understanding with the memory allocators is that SLOB is the smallest
and simplest. Its forté is that it uses very little memory which makes
it ideal for embedded systems and is the easiest allocator to
understand. The downside is that it might tend towards memory
fragmentation the longer a system runs and is apparently a little bit
slower than SLAB. The SLAB allocator is something that the linux kernel
has had for many years and was a good performer until the pressures to
perform with large SMP systems started to come in to play (at which
point lots of memory would be used up on fixed structures -
http://lwn.net/Articles/229984/ ). SLUB is the newest allocator, scales
up well and has finer grained diagnostics that SLAB.

Prior to today my understanding was that SLUB would be able to replace
SLAB in all scenarios and perform just as well or better. However now
I'm not so sure (SLAB appears to be less latent than SLUB). Other than
SLUB's newness are there cases where SLAB should be chosen instead of
SLUB (e.g. uniprocessor desktop systems with hundreds of megabytes of
RAM)? Will SLAB exist as an alternative to SLUB for certain setups?

--
Sitsofe | http://sucs.org/~sits
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2008-10-04 12:53    [W:0.059 / U:0.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site