From: Peter Seebach <peter.seebach@windriver.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 1/6] kenrel.h: add ALIGN_OF_LAST_BIT()
Date: Tue, 20 Mar 2012 09:20:58 -0500 [thread overview]
Message-ID: <20120320092058.1b3271a4@wrlaptop> (raw)
In-Reply-To: <op.wbgvn00x3l0zgt@mpn-glaptop>
On Tue, 20 Mar 2012 12:32:14 +0100
Michal Nazarewicz <mina86@mina86.com> wrote:
> >+#define ALIGN_OF_LAST_BIT(x) ((((x)^((x) - 1))>>1) + 1)
>
> Wouldn't ALIGNMENT() be less confusing? After all, that's what this
> macro is calculating, right? Alignment of given address.
Why not just LAST_BIT(x)? It's not particularly specific to pointer
alignment, even though that's the context in which it apparently came
up. So far as I can tell, this isn't even meaningfully defined on
pointer types as such; you'd have to convert. So the implications for
alignment seem a convenient side-effect, really.
It might be instructive to see some example proposed uses; the question
of why I'd care what alignment something had, rather than whether it
was aligned for a given type, is one that will doubtless keep me awake
nights.
I guess this feels like it answers a question that is usually the wrong
question. Imagine if you will a couple-page block of memory, full of
unsigned shorts. Iterate through the array, calculating
ALIGN_OF_LAST_BIT(&a[i]). Do we really *care* that it's PAGE_SIZE for
some i, and 2 (I assume) for other i, and PAGE_SIZE*2 for either i==0 or
i==PAGE_SIZE? (Apologies if this is a silly question; maybe this is
such a commonly-needed feature that it's obvious.)
-s
--
Listen, get this. Nobody with a good compiler needs to be justified.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Peter Seebach <peter.seebach@windriver.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [RFC PATCH 1/6] kenrel.h: add ALIGN_OF_LAST_BIT()
Date: Tue, 20 Mar 2012 09:20:58 -0500 [thread overview]
Message-ID: <20120320092058.1b3271a4@wrlaptop> (raw)
In-Reply-To: <op.wbgvn00x3l0zgt@mpn-glaptop>
On Tue, 20 Mar 2012 12:32:14 +0100
Michal Nazarewicz <mina86@mina86.com> wrote:
> >+#define ALIGN_OF_LAST_BIT(x) ((((x)^((x) - 1))>>1) + 1)
>
> Wouldn't ALIGNMENT() be less confusing? After all, that's what this
> macro is calculating, right? Alignment of given address.
Why not just LAST_BIT(x)? It's not particularly specific to pointer
alignment, even though that's the context in which it apparently came
up. So far as I can tell, this isn't even meaningfully defined on
pointer types as such; you'd have to convert. So the implications for
alignment seem a convenient side-effect, really.
It might be instructive to see some example proposed uses; the question
of why I'd care what alignment something had, rather than whether it
was aligned for a given type, is one that will doubtless keep me awake
nights.
I guess this feels like it answers a question that is usually the wrong
question. Imagine if you will a couple-page block of memory, full of
unsigned shorts. Iterate through the array, calculating
ALIGN_OF_LAST_BIT(&a[i]). Do we really *care* that it's PAGE_SIZE for
some i, and 2 (I assume) for other i, and PAGE_SIZE*2 for either i==0 or
i==PAGE_SIZE? (Apologies if this is a silly question; maybe this is
such a commonly-needed feature that it's obvious.)
-s
--
Listen, get this. Nobody with a good compiler needs to be justified.
next prev parent reply other threads:[~2012-03-20 14:22 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 10:21 [RFC PATCH 0/6] add kmalloc_align() Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 10:21 ` [RFC PATCH 1/6] kenrel.h: add ALIGN_OF_LAST_BIT() Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 11:32 ` Michal Nazarewicz
2012-03-20 11:32 ` Michal Nazarewicz
2012-03-20 14:03 ` Alexey Dobriyan
2012-03-20 14:03 ` Alexey Dobriyan
2012-03-20 14:08 ` Christoph Lameter
2012-03-20 14:20 ` Peter Seebach [this message]
2012-03-20 14:20 ` Peter Seebach
2012-03-20 10:21 ` [RFC PATCH 2/6] slub: add kmalloc_align() Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 14:14 ` Christoph Lameter
2012-03-20 14:14 ` Christoph Lameter
2012-03-20 14:21 ` Christoph Lameter
2012-03-20 14:21 ` Christoph Lameter
2012-03-20 10:21 ` [RFC PATCH 3/6] slab: " Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 10:21 ` [RFC PATCH 4/6] slob: don't couple the header size with the alignment Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 10:21 ` [RFC PATCH 5/6] slob: add kmalloc_align() Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 10:21 ` [RFC PATCH 6/6] workqueue: use kmalloc_align() instead of hacking Lai Jiangshan
2012-03-20 10:21 ` Lai Jiangshan
2012-03-20 15:15 ` Christoph Lameter
2012-03-20 15:15 ` Christoph Lameter
2012-03-20 15:46 ` Tejun Heo
2012-03-20 15:46 ` Tejun Heo
2012-03-21 3:02 ` Lai Jiangshan
2012-03-21 3:02 ` Lai Jiangshan
2012-03-21 5:14 ` Tejun Heo
2012-03-21 5:14 ` Tejun Heo
2012-03-21 14:12 ` Patch workqueue: create new slab cache " Christoph Lameter
2012-03-21 14:12 ` Christoph Lameter
2012-03-21 14:49 ` Eric Dumazet
2012-03-21 14:49 ` Eric Dumazet
2012-03-21 15:03 ` Christoph Lameter
2012-03-21 15:03 ` Christoph Lameter
2012-03-21 16:04 ` Eric Dumazet
2012-03-21 16:04 ` Eric Dumazet
2012-03-21 17:54 ` Christoph Lameter
2012-03-21 17:54 ` Christoph Lameter
2012-03-21 18:05 ` Eric Dumazet
2012-03-21 18:05 ` Eric Dumazet
2012-03-21 18:20 ` Christoph Lameter
2012-03-21 18:20 ` Christoph Lameter
2012-03-21 16:09 ` Tejun Heo
2012-03-21 16:09 ` Tejun Heo
2012-03-21 17:56 ` Christoph Lameter
2012-03-21 17:56 ` Christoph Lameter
2012-03-21 13:45 ` [RFC PATCH 6/6] workqueue: use kmalloc_align() " Christoph Lameter
2012-03-21 13:45 ` Christoph Lameter
2012-03-26 2:00 ` Lai Jiangshan
2012-03-26 2:00 ` Lai Jiangshan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120320092058.1b3271a4@wrlaptop \
--to=peter.seebach@windriver.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mina86@mina86.com \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.