public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@yahoo.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Christoph Lameter <clameter@sgi.com>
Subject: Reading EeePC900 battery info causes stalls when using SLUB (was Re: How how   latent should non-preemptive scheduling be?)
Date: Sat, 04 Oct 2008 11:50:48 +0100	[thread overview]
Message-ID: <48E74A88.50904@yahoo.com> (raw)
In-Reply-To: <48E22720.9030603@yahoo.com>

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

      reply	other threads:[~2008-10-04 10:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.ERZTl/6uH+mhNoef5fPJKTRjJag@ifi.uio.no>
     [not found] ` <fa.PtPFzP5kIJVCCov6YCewrh+o4z4@ifi.uio.no>
     [not found]   ` <fa.C6WSm5Rh2Nb+Qho7b0qDOZ9RPV8@ifi.uio.no>
     [not found]     ` <fa.ch6j4qXs/2sFpLkHz5fXrtjTR8c@ifi.uio.no>
     [not found]       ` <fa.Jx/Ygtm46CVRawlA6OnfYNn6cN0@ifi.uio.no>
2008-09-18  7:26         ` How how latent should non-preemptive scheduling be? Sitsofe Wheeler
     [not found]         ` <fa.iIHgL48F3T5VAqFw3mqaf9Pzrs4@ifi.uio.no>
     [not found]           ` <fa.Td8xkKZKMSMghlJmEYefTRVF2kc@ifi.uio.no>
2008-09-19 11:54             ` Sitsofe Wheeler
2008-09-19 14:20               ` Peter Zijlstra
2008-09-22 11:57               ` Ingo Molnar
2008-09-22 12:07                 ` Steven Rostedt
2008-09-23  6:33                 ` Sitsofe Wheeler
2008-09-23 11:53                   ` Ingo Molnar
2008-09-23 16:30                     ` Sitsofe Wheeler
2008-09-23 19:39                       ` Sitsofe Wheeler
2008-09-23 22:01                         ` Sitsofe Wheeler
2008-09-27 20:48                           ` Ingo Molnar
2008-09-28 20:56                             ` Sitsofe Wheeler
2008-09-29  8:37                               ` Ingo Molnar
2008-09-29 23:11                                 ` Sitsofe Wheeler
2008-09-30 11:22                                   ` Ingo Molnar
2008-09-30 13:18                                     ` Sitsofe Wheeler
2008-10-04 10:50                                       ` Sitsofe Wheeler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48E74A88.50904@yahoo.com \
    --to=sitsofe@yahoo.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox