linux-kernel - Re: linux+glibc memory allocator, poor performance

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-next>] [day] [month] [year] [list]

Date:	Wed, 12 Mar 2008 21:09:04 +0100
From:	"J.C. Pizarro" <jcpiza@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: linux+glibc memory allocator, poor performance

On Wed, 12 Mar 2008 19:14:06 +0100, Xose Vazquez Perez wrote:
> hi,
>
> More tests from FreeBSD people <http://people.freebsd.org/~kris/scaling/smp.html>
>
> Poor performance with 2.6.24 linux kernel and glibc 2.7 provided by Fedora 8:
>
> *Memory allocation performance on FreeBSD and Linux with ebizzy (Mar 2008)*
> <http://people.freebsd.org/~kris/scaling/ebizzy.html>
>
> -thanks-
>
> regards,
> --
> so much to do, so little time.

Assume a SMP system that has 8 CPUs. The main problem of requesting
pages is the BKL (Big Kernel Lock) in this SMP system used for mutual
exclusion of the shared resource (the memory).

To solve this major problem, i propose you freely to allocate 8 local caches
of (e.g.) 2 MiB each CPU (total 2MiB x 8 CPUs = 16 MiB) acting as
8 producer buffers for globally many consumer tasks (e.g. >= 20).

When the some producer buffer is empty then it does unfrequently BKL to
allocate another 2 MiB more from the shared resource (the memory).

In the reverse, it's simple, return back the unused pages to the local buffer
of the producer, and when this full then to do BKL too to unallocate its half
to the shared resource (the memory).

   Sincerely, J.C.Pizarro
--
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/