[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOS58YPydFUap4HjuRATxza6VZgyrXmQHVxR83G7GRJL50ZTRQ@mail.gmail.com>
Date: Tue, 20 Mar 2012 22:14:05 -0700
From: Tejun Heo <tj@...nel.org>
To: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Pekka Enberg <penberg@...nel.org>,
Christoph Lameter <cl@...ux-foundation.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
Hello,
On Tue, Mar 20, 2012 at 8:02 PM, Lai Jiangshan <laijs@...fujitsu.com> 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.
>
> o SLAB/SLUB's kmalloc-objects are natural/automatic aligned.
> o 70LOC in total, and about 90% are just renaming or wrapping.
>
> I think it is a worth trade-off, it give us convenience and we pay
> zero overhead(when runtime) and 70LOC(when coding, pay in a lump sum).
>
> 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.
Ooh, don't be sorry. My only concern is that it doesn't have any user
other than cwq allocation. If you can find other cases which can
benefit from it, it would be great.
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists