public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Weeks <greg.weeks@timesys.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.4] jffs2 aligment problems
Date: Mon, 07 Jun 2004 21:39:31 +0100	[thread overview]
Message-ID: <1086640771.29255.57.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0406071218240.1637@ppc970.osdl.org>

On Mon, 2004-06-07 at 12:22 -0700, Linus Torvalds wrote:
> I don't see it as a correctness issue, I see it as a performance issue.

In the case in question it's very much _not_ a performance issue. We're
writing a buffer to FLASH memory. The time it takes to read the word
from RAM is entirely lost in the noise compared with the time it takes
to write it to the flash.

Most of the time the buffer passed to the flash write routines will be
word-aligned. Occasionally it'll be unaligned but since there's a
distinct correlation between those arches on which we can't do fixups
and those machines on which flash is primary storage, putting
get_unaligned() in is a _correctness_ issue. And I don't care that it
might be slightly slower in the common case; as I said, it's in the
noise.

> Yes, the old ARM chips that can't do unaligned accesses and can't even 
> trap on them probably have a number of cases where they literally do the 
> wrong thing, and I think most people will say "tough luck, don't do that 
> then". 

Not just old ARM chips. Some new chips too; especially MMU-less ones.

> But get_unaligned() makes sense quite apart from that usage too. Notably, 
> many architectures can cheaply do unaligned accesses when they are known 
> to be unaligned, but take thousands of cycles to fix up traps. Alpha comes 
> to mind, and this was actually what "get_unaligned()" was really designed 
> for.

Yes. That's why I suggested we should have two forms -- for 'possibly'
and 'probably' unaligned.

> > Anything which _could_ be unaligned should be marked as such, even if we
> > do have two levels ('possibly unaligned', 'probably unaligned') where
> > the latter behaves purely as an optimisation on most arches, just like
> > our current get_unaligned() does.
> 
> Right now we might as well consider the "get_unaligned()" to be a "quite 
> possibly unaligned" as opposed to "this just _might_ be unaligned".

Yes. That's why I was told to remove our current get_unaligned() from
the flash drivers. I'm perfectly happy to put it back.


-- 
dwmw2


  reply	other threads:[~2004-06-07 20:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-07 15:08 [PATCH 2.4] jffs2 aligment problems Greg Weeks
2004-06-07 15:36 ` Thomas Gleixner
2004-06-07 16:03   ` Linus Torvalds
2004-06-07 16:41     ` Russell King
2004-06-07 19:14       ` David Woodhouse
2004-06-07 19:22         ` Linus Torvalds
2004-06-07 20:39           ` David Woodhouse [this message]
2004-06-07 20:54             ` Linus Torvalds
2004-06-07 20:56               ` Thomas Gleixner
2004-06-07 21:29                 ` David Woodhouse
2004-06-07 21:40                   ` Thomas Gleixner

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=1086640771.29255.57.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=greg.weeks@timesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=tglx@linutronix.de \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox