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 linux-cve-announce 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]

Message-ID: <84144f020712090118w27225592w8933ee2314db7556@mail.gmail.com>
Date:	Sun, 9 Dec 2007 11:18:00 +0200
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"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]

Hi Ingo,

On Dec 9, 2007 10:50 AM, Ingo Molnar <mingo@...e.hu> wrote:
> yes, i understand the initial announcement (and the Kconfig entry still
> says the same), but that is not matched up by the reality i see in the
> actual code - SLUB clearly uses a queue/list of objects (as cited in my
> previous mail), for obvious performance reasons.
>
> unless i'm missing something obvious (and i easily might), i see SLUB as
> SLAB reimplemented with a different queueing model. Not "without
> queueing".

Sure, the emphasis is on "no *such* queues."

On Dec 9, 2007 10:50 AM, Ingo Molnar <mingo@...e.hu> wrote:
> i'm curious about the real facts behind this "alien cache problem". I
> heard about it and asked around and was told that there's some sort of
> bad quadratic behavior of memory consumption on NUMA - but i cannot
> actually see that in the code.

I mostly live in the legacy 32-bit UMA/UP land still so I cannot verify this
myself but the kind folks at SGI claim the following (again from the
announcement):

"On our systems with 1k nodes / processors we have several gigabytes
 just tied up for storing references to objects for those queues  This does
 not include the objects that could be on those queues. One fears that the
 whole memory of the machine could one day be consumed by those
 queues."

The problem is that for each cache, you have an "per-node alien queues"
for each node (see struct kmem_cache nodelists -> struct kmem_list3 alien).
Moving slab metadata to struct page solves this but now you can only have
one "queue" thats part of the same struct.

                        Pekka
--
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/