Messages in this thread | | | Date | Tue, 1 Dec 2009 14:41:44 -0800 (PST) | From | David Rientjes <> | Subject | Re: lockdep complaints in slab allocator |
| |
On Mon, 30 Nov 2009, Matt Mackall wrote:
> And it's not even something that -most- of embedded devices will want to > use, so it can't be keyed off CONFIG_EMBEDDED anyway. If you've got even > 16MB of memory, you probably want to use a SLAB-like allocator (ie not > SLOB). But there are -millions- of devices being shipped that don't have > that much memory, a situation that's likely to continue until you can > fit a larger Linux system entirely in a <$1 microcontroller-sized device > (probably 5 years off still). >
What qualifying criteria can we use to automatically select slob for a kernel or the disqualifying criteria to automatically select slub as a default, then? It currently depends on CONFIG_EMBEDDED, but it still requires the user to specifically chose the allocator over another. Could we base this decision on another config option enabled for systems with less than 16MB?
> This thread is annoying. The problem that triggered this thread is not > in SLOB/SLUB/SLQB, nor even in our bog-standard 10yo deep-maintenance > known-to-work SLAB code. The problem was a FALSE POSITIVE from lockdep > on code that PREDATES lockdep itself. There is nothing in this thread to > indicate that there is a serious problem maintaining multiple > allocators. In fact, considerably more time has been spent (as usual) > debating non-existent problems than fixing real ones. >
We could move the discussion on the long-term maintainable aspects of multiple slab allocators to a new thread if you'd like.
| |