Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
Cc: kirill@shutemov.name, starvik@axis.com, linux@roeck-us.net,
	jespern@axis.com, hughd@google.com,
	kirill.shutemov@linux.intel.com, linux-next@vger.kernel.org,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	minchan@kernel.org, linux-cris-kernel@axis.com
Subject: Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'
Date: Tue, 22 Sep 2015 08:18:35 -0700
Message-ID: <20150922151835.GM4029@linux.vnet.ibm.com> (raw)
In-Reply-To: <201509221357.t8MDv6G5015271@ignucius.se.axis.com>

On Tue, Sep 22, 2015 at 03:57:06PM +0200, Hans-Peter Nilsson wrote:
> > From: "Kirill A. Shutemov" <kirill@shutemov.name>
> > Date: Tue, 22 Sep 2015 15:27:51 +0200
> 
> > On Tue, Sep 22, 2015 at 02:50:19PM +0200, Hans-Peter Nilsson wrote:
> > > That element (the struct) needs *explicit* padding or alignment
> > > to the required multiplicity of bytes for anyone to portably be
> > > able to imply something other than "byte alignment" for the
> > > layout of it, as elements of an array, across systems.  Use
> > > dummy elements or a compiler construct like __attribute__
> > > ((__aligned__ (...))) per kernel policy or taste.  I'd recommend
> > > specifying the alignment, so TRT will happen for it when it in
> > > turn is an element of an otherwise unpadded struct.
> 
> > I see. I would say it's very risky ABI choice, but okay.
> > 
> > What was the reason behind? I don't understand it.
> 
> It was made some 20+ years ago, some of the reason being (here's
> the irony) compatibility with a toolchain for another
> architecture, popular at the time, now forgotten.
> Another reason (IIRC) was that it saves space. :)
> 
> > Is it free to make misaligned memory access on CRIS?
> 
> Within a cache-line for CRIS v32, it's free.
> 
> > What about atomicity? How it works for misaligned accesses?
> 
> Good spotting.  No system with page layouts fixed at size
> multiples (all are, it'd be crazy to split pages as low as byte
> boundaries) can support naturally-misaligned atomic accesses.
> 
> Therefore elements with access expecting atomicity, have be
> decorated with alignment-inducing attributes, for portability,
> e.g. to work for CRIS.  In userspace, I can at times get away
> with calling a special function with a process-wide lock, in
> those cases where the upstream project is unlikely to timely
> understand e.g. that a naked "int" is not naturally aligned.
> 
> > The patch below fixes issue for me.
> 
> Thanks.
> 
> > I'm not sure if we want to ask for alignment to sizeof(long).
> > aligned(2) works too.
> 
> I guess you hit the right spot, but I'd think people would be
> more comfortable with aligning to sizeof (void *).

I would indeed prefer sizeof(void *).

						Thanx, Paul

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17 16:29 Guenter Roeck
2015-09-18 14:25 ` Kirill A. Shutemov
2015-09-18 14:53   ` Jesper Nilsson
2015-09-18 15:13     ` Guenter Roeck
2015-09-21 15:34       ` Kirill A. Shutemov
2015-09-22  1:17         ` Guenter Roeck
2015-09-22 12:03           ` Kirill A. Shutemov
2015-09-22 12:19             ` Mikael Starvik
2015-09-22 12:50               ` Hans-Peter Nilsson
2015-09-22 13:27                 ` Kirill A. Shutemov
2015-09-22 13:57                   ` Hans-Peter Nilsson
2015-09-22 15:18                     ` Paul E. McKenney [this message]
2015-09-22 15:31                       ` Kirill A. Shutemov
2015-09-22 15:40                         ` Paul E. McKenney
2015-09-23 10:53                           ` Kirill A. Shutemov
2015-09-23 15:02                             ` Guenter Roeck
2015-09-24  4:45                               ` Paul E. McKenney
2015-09-22 16:16                         ` Hans-Peter Nilsson
2015-09-22 16:39                           ` Paul E. McKenney

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=20150922151835.GM4029@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=hughd@google.com \
    --cc=jespern@axis.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-cris-kernel@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=minchan@kernel.org \
    --cc=starvik@axis.com \
    /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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git