From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Christoph Lameter <christoph@lameter.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Alok N Kataria <alokk@calsoftinc.com>,
Shobhit Dayal <shobhit@calsoftinc.com>,
Shai Fultheim <shai@scalex86.org>, Matt Mackall <mpm@selenic.com>,
Andrew Morton <akpm@osdl.org>, john stultz <johnstul@us.ibm.com>,
Gunter Ohrner <G.Ohrner@post.rwth-aachen.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RT 00/02] SLOB optimizations
Date: Wed, 21 Dec 2005 07:36:07 +0100 [thread overview]
Message-ID: <20051221063607.GA766@elte.hu> (raw)
In-Reply-To: <1135116715.13138.409.camel@localhost.localdomain>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=113510997009883&w=2
> >
> > Quite a long list of unsupported features. These academic papers
> > usually only focus on one thing. The SLAB allocator has to work
> > for a variety of situations though.
> >
> > It would help to explain what ultimately will be better in the new slab
> > allocator. The complexity could be taken care of by reorganizing the code.
>
> Honestly, what I would like is a simpler solution, whether we go with
> a new approach or reorganize the current slab. I need to get -rt
> working, and the code in slab is pulling my resources more than they
> can extend. I'm capable to convert slab today as it is for RT but it
> will probably take longer than I can afford.
please, lets let the -rt tree out of the equation. The SLAB code is fine
on upstream, and it was a pure practical maintainance decision to go for
SLOB in the -rt tree. Yes, the SLAB code is complex, but i could hardly
list any complexity in it tht isnt justified with a performance
argument. _Maybe_ the SLAB code could be further cleaned up, maybe it
could even be replaced, but we'd have to see the patches first. In any
case, the -rt tree is not an argument that matters.
Ingo
next prev parent reply other threads:[~2005-12-21 6:37 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-16 11:30 2.6.15-rc5-rt2 slowness Gunter Ohrner
2005-12-16 11:42 ` Gunter Ohrner
2005-12-16 12:04 ` Gunter Ohrner
2005-12-16 12:34 ` Steven Rostedt
2005-12-16 12:32 ` Steven Rostedt
2005-12-16 22:58 ` john stultz
2005-12-17 0:22 ` Gunter Ohrner
2005-12-17 3:51 ` Steven Rostedt
2005-12-17 3:33 ` Steven Rostedt
2005-12-17 22:57 ` Steven Rostedt
2005-12-18 16:05 ` K.R. Foley
2005-12-20 13:32 ` Ingo Molnar
2005-12-20 13:38 ` Steven Rostedt
2005-12-20 13:57 ` Ingo Molnar
2005-12-20 14:04 ` Steven Rostedt
2005-12-20 14:33 ` Steven Rostedt
2005-12-20 15:07 ` Ingo Molnar
2005-12-20 15:16 ` Steven Rostedt
2005-12-20 15:44 ` [PATCH RT 00/02] SLOB optimizations Steven Rostedt
2005-12-20 15:56 ` Steven Rostedt
2005-12-20 15:58 ` Ingo Molnar
2005-12-20 16:13 ` Ingo Molnar
2005-12-20 16:29 ` Steven Rostedt
2005-12-20 16:39 ` Steven Rostedt
2005-12-20 18:19 ` Matt Mackall
2005-12-20 19:15 ` Steven Rostedt
2005-12-20 19:43 ` Matt Mackall
2005-12-20 20:06 ` Steven Rostedt
2005-12-20 20:15 ` Pekka Enberg
2005-12-20 21:42 ` Steven Rostedt
2005-12-20 21:52 ` Christoph Lameter
2005-12-20 22:11 ` Steven Rostedt
2005-12-21 6:36 ` Ingo Molnar [this message]
2005-12-21 12:50 ` Steven Rostedt
2005-12-21 6:56 ` Ingo Molnar
2005-12-21 7:16 ` Pekka J Enberg
2005-12-21 7:50 ` Ingo Molnar
2005-12-21 13:13 ` Steven Rostedt
2005-12-21 15:34 ` [PATCH] SLAB - have index_of bug at compile time Steven Rostedt
2005-12-21 7:20 ` [PATCH RT 00/02] SLOB optimizations Eric Dumazet
2005-12-21 7:43 ` Ingo Molnar
2005-12-21 8:02 ` Eric Dumazet
2005-12-22 18:02 ` Zwane Mwaikambo
2005-12-22 21:11 ` Ingo Molnar
2005-12-22 21:39 ` Eric Dumazet
2005-12-22 21:44 ` George Anzinger
2005-12-22 22:00 ` Eric Dumazet
2005-12-22 22:08 ` Eric Dumazet
2005-12-23 19:22 ` Zwane Mwaikambo
2005-12-21 13:02 ` Steven Rostedt
2005-12-21 2:30 ` Nick Piggin
2005-12-21 2:41 ` Steven Rostedt
2005-12-20 15:44 ` [PATCH RT 01/02] SLOB - remove bigblock list Steven Rostedt
2005-12-20 15:44 ` [PATCH RT 02/02] SLOB - break SLOB up by caches Steven Rostedt
2005-12-20 14:07 ` 2.6.15-rc5-rt2 slowness Steven Rostedt
2005-12-20 15:26 ` K.R. Foley
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=20051221063607.GA766@elte.hu \
--to=mingo@elte.hu \
--cc=G.Ohrner@post.rwth-aachen.de \
--cc=akpm@osdl.org \
--cc=alokk@calsoftinc.com \
--cc=christoph@lameter.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=rostedt@goodmis.org \
--cc=shai@scalex86.org \
--cc=shobhit@calsoftinc.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.