linux-kernel - Re: [MODSLAB 3/7] A Kmalloc subsystem

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 19 Aug 2006 09:46:18 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Manfred Spraul <manfred@...orfullife.com>
cc:	Andi Kleen <ak@....de>, mpm@...enic.com,
	Marcelo Tosatti <marcelo@...ck.org>,
	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>, Andi Kleen <ak@...e.de>,
	Dave Chinner <dgc@....com>
Subject: Re: [MODSLAB 3/7] A Kmalloc subsystem

On Sat, 19 Aug 2006, Manfred Spraul wrote:

> What about:
> 
> if (unlikely(addr & (~(PAGE_SIZE-1))))
>    slabp=virt_to_page(addr)->pagefield;
> else
>    slabp=addr & (~(PAGE_SIZE-1));

Well this would not be working with the simple slab design that puts the 
first element at the page border to simplify alignment.

And as we have just seen virt to page is mostly an address 
calculation in many configurations. I doubt that there would be a great 
advantage. Todays processors biggest cause for latencies are 
cacheline misses.. Some arithmetic with addresses does not seem to 
be that important. Misaligning data in order to not put objects on such
boundaries could be an issue.

 > Modify the kmalloc caches slightly and use non-power-of-2 cache sizes. Move
> the kmalloc(PAGE_SIZE) users to gfp.

Power of 2 cache sizes make the object align neatly to cacheline 
boundaries and make them fit tightly into a page.

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