linux-kernel - Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Dec 2007 21:29:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <clameter@....com>
Subject: Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52,
	[2.6.24-rc4-git5: Reported regressions from 2.6.23]


* Ingo Molnar <mingo@...e.hu> wrote:

> the SLUB concept is proudly outlined in init/Kconfig:
> 
>   config SLUB
>         bool "SLUB (Unqueued Allocator)"
>         help
>            SLUB is a slab allocator that minimizes cache line usage
>            instead of managing queues of cached objects (SLAB approach).
>            Per cpu caching is realized using slabs of objects instead
>            of queues of objects. SLUB can use memory efficiently
>            and has enhanced diagnostics.
> 
> but that's not true anymore - the two concepts are pretty much 
> equivalent, after all the "performance tuning" that went on in SLUB. 
> (read: 'frantically try to catch up with SLAB in benchmarks')

just to hammer this point home - and while Christoph Lameter isnt online 
currently to defend SLUB, this issue did come up and i guess there must 
be other MM hackers that are advocates of SLUB. (otherwise this code 
couldnt be upstream)

I find SLUB a fantastically confusing concept, and that starts at the 
name. "Unqueued" it says. Lets take a look at the actual code:

mm/slub.c:

  static void __always_inline *slab_alloc(struct kmem_cache *s,
                  gfp_t gfpflags, int node, void *addr)
  {
  ...
          local_irq_save(flags);
          c = get_cpu_slab(s, smp_processor_id());
  ...
          else {
                  object = c->freelist;
                  c->freelist = object[c->offset];
          }
          local_irq_restore(flags);

so it has a "free list", which is clearly per cpu. Hang on! Isnt that 
actually a per CPU queue? Which SLUB has not, we are told? The "U" in 
SLUB. How on earth can an allocator in 2007 claim to have no queuing
(which is in essence caching)? Am i on crack with this? Did i miss
something really obvious?

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