public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: David Miller <davem@davemloft.net>,
	torvalds@linux-foundation.org, mingo@kernel.org, x86@kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: x86: faster strncpy_from_user()
Date: Wed, 11 Apr 2012 09:56:51 +1000	[thread overview]
Message-ID: <1334102211.2984.4.camel@pasglop> (raw)
In-Reply-To: <4F84C35C.1020803@zytor.com>

On Tue, 2012-04-10 at 16:33 -0700, H. Peter Anvin wrote:
> > Just wanted to mention that handling the detect zeroes operations on
> > cpus that require alignment is easy, just rewind the pointer at the
> > beginning to be aligned and "or" in a mask of 0xff for each alignment
> > pad byte into the initially loaded word.
> > 
> 
> Even on machines which don't require alignment it will still be faster
> to do aligned memory references only, not counting the startup cost
> (which is substantial in this case, of course, since the average length
> is so short.)  However, it also neatly avoids the page overrun problem.

I'm leaning toward that too, but I want to do some benches. The main
issues for me are:

  - I have to deal with a reasonably wide range of different cores which
will handle unaligned accesses very differently. Almost all will do it
in HW but with very varying degree of performances and some will
occasionally trap (SW emulation kicks in but that's extremely slow). The
trapping case is generally rare though, depending on the core it will
happen on things like page boundaries or segment boundaries. I also
suspect that the byte-reverse load/store instructions will suck more at
unaligned.

 - The page overrun is an issue. On 64-bit we don't have anything mapped
past the end of the linear mapping and on 32-bit we fall into ioremap
space. That's fixable with a quick hack to add one more page to the
linear mapping, creating a double mapping of either page 0 or any random
page of memory, I don't have cache aliases or anything like that to
worry about but it's gross.

Anyways, I'll try to play around if I get time, might have to wait for
next week tho, I have some more urgent stuff to sort out and I'm off
friday to tuesday.

Cheers,
Ben.

  reply	other threads:[~2012-04-10 23:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-06 21:32 x86: faster strncpy_from_user() Linus Torvalds
2012-04-06 21:49 ` Linus Torvalds
2012-04-10 22:35 ` Benjamin Herrenschmidt
2012-04-10 22:50   ` Linus Torvalds
2012-04-10 23:29     ` David Miller
2012-04-10 23:33       ` H. Peter Anvin
2012-04-10 23:56         ` Benjamin Herrenschmidt [this message]
2012-04-10 23:25   ` David Miller
2012-04-11  0:34     ` Linus Torvalds
2012-04-11  0:43       ` David Miller
2012-04-11  0:50         ` Linus Torvalds
2012-04-11  0:57           ` Linus Torvalds
2012-04-11  1:09             ` David Miller
2012-04-11  1:18               ` Linus Torvalds
2012-04-11  1:25             ` Benjamin Herrenschmidt
2012-04-11  8:22               ` Geert Uytterhoeven

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=1334102211.2984.4.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox