From: Oleg Verych <olecom@flower.upol.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>,
Al Viro <viro@ftp.linux.org.uk>,
akpm@linux-foundation.org, benh@kernel.crashing.org,
linux-kernel@vger.kernel.org, hpa@zytor.com,
johannes@sipsolutions.net
Subject: Re: ALIGN (Re: [PATCH] Fix get_order())
Date: Sat, 10 Mar 2007 01:31:41 +0100 [thread overview]
Message-ID: <20070310003140.GC17084@flower.upol.cz> (raw)
In-Reply-To: <Pine.LNX.4.64.0703091509180.10832@woody.linux-foundation.org>
On Fri, Mar 09, 2007 at 03:15:10PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 10 Mar 2007, Oleg Verych wrote:
> >
> > OTOH, if i would write it this way
> >
> > #define BALIGN(x,bits) ((((x) >> (bits)) + 1) << (bits))
>
> But that's *wrong*. It aligns something that is *already* aligned to
> something else.
Indeed. I'm confused by semantics of ALIGN macro, as from C arithmetic
side, as from using side. Former confusion also yields patches like
(Fix 'ALIGN()' macro, take 2), fixing that, i was wonder about.
BALIGN is like do-this alignment, and must be
void do_align(what, bits)
instead. While clear arithmetic (optimized in assembler, shifts are
C shifts!), it fails in value(alignment(what, how)) kind of thing.
> So you'd have to do it as something like
>
> #define ALIGN_TO_POW2(x,pow) \
> ((((x)+(1<<(pow))-1)>>(pow))<<(pow))
>
> and the thing is, that's actually both (a) less readable than what ALIGN()
> already does (b) unless the compiler notices that what you really want is
> a "bitwise and", it's really inefficient too because shifts are generally
> much more expensive than simple bitops.
>
> So you're simply better off doing it as
>
> #define ALIGN_TO_POW2(x,pow) ALIGN(x, (1ull << pow))
>
> but then you'd still have to depend on the "typeof()" magic in ALIGN() to
> turn the final end result back to the type of "x".
>
> (the "1ull" is necessary exactly because you don't know what type "x" is
> beforehand, so you need to make sure that the mask is at *least* as big a
> type as x, and not overflow to undefined C semantics).
Via typeof() *feature* and 1U, 1UL, 1ULL *things*, i (we?) have that, what
is described above.
Examples of using ALIGN. As that, i've picked earlier,
arch/powerpc/mm/hugetlbpage.c: addr = ALIGN(addr+1,1UL<<HTLB_AREA_SHIFT);
arch/powerpc/mm/hugetlbpage.c: addr = ALIGN(addr+1,1<<SID_SHIFT);
mixes two things, and i can't understand what is meant here,
lib/swiotlb.c: io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
lib/swiotlb.c: io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
lib/swiotlb.c: io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
clear "do align", etc.
So, maybe spitting "do align" (with C shifts, without C arithmetics
error-prone-due-to-C magic) and "alignment" isn't a bad idea.
Easiness is what i wanted to have. For example, like in this clean up,
'proper memory-mapped accesses rather than making up our own "volatile"
pointers' in 6c0ffb9d2fd987c79c6cbb81c3f3011c63749b1a. Clear C-vs-call()
rewrite.
Sorry, if i'm barking up the wrong tree here.
____
next prev parent reply other threads:[~2007-03-10 0:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 17:39 [PATCH] Fix get_order() David Howells
2007-03-06 17:58 ` H. Peter Anvin
2007-03-06 18:21 ` David Howells
2007-03-06 18:41 ` Linus Torvalds
2007-03-06 18:51 ` David Howells
2007-03-07 3:28 ` Linus Torvalds
2007-03-07 11:43 ` David Howells
2007-03-07 16:02 ` ALIGN via ilog2 without gccisms (Re: [PATCH] Fix get_order()) Oleg Verych
2007-03-07 16:38 ` Linus Torvalds
2007-03-07 17:24 ` Oleg Verych
2007-03-07 18:05 ` Linus Torvalds
2007-03-09 23:13 ` ALIGN " Oleg Verych
2007-03-09 23:15 ` Linus Torvalds
2007-03-10 0:31 ` Oleg Verych [this message]
2007-03-10 8:01 ` ALIGN Oleg Verych
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=20070310003140.GC17084@flower.upol.cz \
--to=olecom@flower.upol.cz \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ftp.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®