All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Akira Tsukamoto <at541@columbia.edu>
Cc: Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org,
	Hirokazu Takahashi <taka@valinux.co.jp>,
	Andrew Morton <akpm@digeo.com>,
	Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Subject: Re: [CFT][PATCH]  2.5.47 Athlon/Druon, much faster copy_user function
Date: Sat, 16 Nov 2002 19:30:03 +0100	[thread overview]
Message-ID: <20021116193003.A11205@wotan.suse.de> (raw)
In-Reply-To: <20021116131403.9FB5.AT541@columbia.edu>

On Sat, Nov 16, 2002 at 01:22:51PM -0500, Akira Tsukamoto wrote:
> On Sat, 16 Nov 2002 11:56:52 +0100
> Andi Kleen <ak@suse.de> mentioned:
> > 
> > You don't seem to save/restore the FPU state, so it will be likely 
> > corrupted after your copy runs.
> 
> This is the main question for me that I was wondering for all week. 
> My first version was using fsave and frstore, so 
> just changing three lines will accomplish this.
> Is it all I need?  Any thing elase needed to consider using fpu register?

You are currently corrupting the user's FPU state.

The proper way to save it is to use kernel_fpu_begin()

> > 
> > Also I'm pretty sure that using movntq (= forcing destination out of 
> > cache) is not a good strategy for generic copy_from_user(). It may 
> > be a win for the copies in write ( user space -> page cache ),
> 
> Yes, that why I included postfetch in the code because movntq does not leave 
> them in the L2 cache.

That looks rather wasteful - first force it out and then trying to get it in 
again. I have my doubts on it being a good strategy for speed.

> > but 
> > will hurt for all the ioctls and other things that actually need the
> > data in cache afterwards. I am afraid it is not enough to do micro benchmarks
> > here.
> 
> check above?

Use special function calls for them, don't put it into generic 
copy_*_user

Also you should really check for small copy and not use the FPU based
copy for them. Best is probably to use a relatively simply copy_*_user
(no FPU tricks, just an unrolled integer core) and change the VFS
and the file systems to call a special function from write(), but only
when the write is big.

-Andi

  reply	other threads:[~2002-11-16 18:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-16  6:53 [CFT][PATCH] 2.5.47 Athlon/Druon, much faster copy_user function Akira Tsukamoto
2002-11-16 10:56 ` Andi Kleen
2002-11-16 18:22   ` Akira Tsukamoto
2002-11-16 18:30     ` Andi Kleen [this message]
2002-11-16 18:50       ` Akira Tsukamoto
2002-11-16 22:23         ` Hirokazu Takahashi
2002-11-16 21:55       ` Akira Tsukamoto

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=20021116193003.A11205@wotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@digeo.com \
    --cc=at541@columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=taka@valinux.co.jp \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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.