All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Andi Kleen <ak@muc.de>
Cc: Denis Vlasenko <vda@ilport.com.ua>,
	dean gaudet <dean-list-linux-kernel@arctic.org>,
	Jeff Garzik <jgarzik@pobox.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] x86-64: Use SSE for copy_page and clear_page
Date: Tue, 31 May 2005 09:59:59 -0400	[thread overview]
Message-ID: <20050531135959.GA16081@kvack.org> (raw)
In-Reply-To: <20050531092358.GA9372@muc.de>

On Tue, May 31, 2005 at 11:23:58AM +0200, Andi Kleen wrote:
> fork is only a corner case. The main case is a process allocating
> memory using brk/mmap and then using it.

At least for kernel compiles, using non-temporal stores is a slight 
win (a 2-5s improvement on 4m30s).  Granted, there seems to be a 
lot of variation in kernel compile times.

A bit more experimentation shows that non-temporal stores plus a 
prefetch of the resulting data is still better than the existing 
routines and only slightly slower than the pure non-temporal version.  
That said, it seems to result in kernel compiles that are on the high 
side of the variations I normally see (4m40s, 4m38s) compared to the 
~4m30s for an unpatched kernel and ~4m25s-4m30s for the non-temporal 
store version.

		-ben
-- 
"Time is what keeps everything from happening all at once." -- John Wheeler

  reply	other threads:[~2005-05-31 13:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-30 18:16 [RFC] x86-64: Use SSE for copy_page and clear_page Benjamin LaHaise
2005-05-30 18:45 ` Jeff Garzik
2005-05-30 19:06 ` dean gaudet
2005-05-30 19:11   ` dean gaudet
2005-05-30 19:32     ` Andi Kleen
2005-05-31  8:37       ` Denis Vlasenko
2005-05-31  9:15         ` Denis Vlasenko
2005-05-31  9:23           ` Andi Kleen
2005-05-31 13:59             ` Benjamin LaHaise [this message]
2005-06-01  6:22               ` Denis Vlasenko
2005-06-01  6:47                 ` Denis Vlasenko
2005-06-01  7:22             ` michael
2005-06-01  7:48               ` Andi Kleen
2005-06-01  7:48               ` Denis Vlasenko
2005-06-01 21:46                 ` dean gaudet
2005-06-01  8:01               ` Nick Piggin
2005-05-30 19:38 ` Andi Kleen
2005-05-30 20:05   ` Michael Thonke
2005-05-30 20:14     ` Benjamin LaHaise
2005-05-30 20:42       ` Michael Thonke
2005-05-31  7:11     ` Andi Kleen

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=20050531135959.GA16081@kvack.org \
    --to=bcrl@kvack.org \
    --cc=ak@muc.de \
    --cc=dean-list-linux-kernel@arctic.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@ilport.com.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.