linux-kernel - Re: [RFC PATCH 6/6] workqueue: use kmalloc

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

Date:	Mon, 26 Mar 2012 10:00:13 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	Christoph Lameter <cl@...ux.com>
CC:	Tejun Heo <tj@...nel.org>, Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH 6/6] workqueue: use kmalloc_align() instead of hacking

On 03/21/2012 09:45 PM, Christoph Lameter wrote:
> On Wed, 21 Mar 2012, Lai Jiangshan wrote:
> 
>> Yes, I don't want to build a complex kmalloc_align(). But after I found
>> that SLAB/SLUB's kmalloc-objects are natural/automatic aligned to
>> a proper big power of two. I will do nothing if I introduce kmalloc_align()
>> except just care the debugging.
> 
> They are not guaranteed to be aligned to the big power of two! There are
> kmalloc caches that are not power of two. Debugging and other
> necessary meta data may change alignment in both SLAB and SLUB. SLAB needs
> a metadata structure in each page even without debugging that may cause
> alignment issues.

"Debugging and other necessary meta data" are handled in special way in my patches.
(You have already checked the patches.)

Normally, as I said, SLAB/SLUB's kmalloc-objects are natural/automatic aligned,
and my patch does not touch the general cases. Sorry for my bad reply.


> 
>> And kmalloc_align() can be used in the following case:
>> o	a type object need to be aligned with cache-line for it contains a frequent
>> 	update-part and a frequent read-part.
>> o	The total number of these objects in a given type is not much, creating
>> 	a new slab cache for a given type will be overkill.
>>
>> This is a RFC patch and it seems mm gurus don't like it. I'm sorry I
>> bother all of you.
> 
> Ideas are always welcome. Please do not get offended by our problems with
> your patch.
> 
> 
> 

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