linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Jamie Lokier <jamie@shareable.org>
Cc: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata  patch
Date: Wed, 1 Oct 2003 09:39:22 +0200	[thread overview]
Message-ID: <20031001073922.GL15853@wotan.suse.de> (raw)
In-Reply-To: <20031001072011.GJ1131@mail.shareable.org>

On Wed, Oct 01, 2003 at 08:20:11AM +0100, Jamie Lokier wrote:
> I think the mmap_sem problems are fixed by an appropriate "address >=
> TASK_SIZE" check at the beginning do_page_fault, which should jump

Assuming vsyscalls never contain prefetch. 

> straight to bad_area_nosemaphore.  As there is already such a check,
> there's no penalty for rearranging the logic there, and it will in
> fact speed up kernel faults slightly by avoiding the mmap_sem and
> find_vma() which are redundant for kernel faults.

I guess that would work, agreed.

I will fix it this way for x86-64.

> 
> I have some ideas for speeding up __is_prefetch().  First, take the
> get_segment_eip() stuff from my patch - that should speed up your
> latest "more checking" slightly, because it replaces the access_ok()
> checks with something slightly tighter.

At least for x86-64 I just switched to checking the three possible
segments explicitely.

Imho that's the best way for 32bit too, non zero segment bases are
just not worth caring about.

> 
> Second, instead of masking and a switch statement, do test_bit on a
> 256-bit vector.  (I admit I'm not quite sure how fast variable
> test_bit is; this is assuming it is quite fast).  If it's zero, return
> 0 from __is_prefetch().  If it's one, it's either a prefix byte to
> skip or 0x0f, to check the next byte for a prefetch.  That'll probably
> make the code smaller too, because the vector is only 32 bytes,
> shorter than the logic in the switch().

I had the same idea earlier, but discarded it because it would make
the code much more ugly. It's better to just keep that stuff out of
the fast path, not optimize it to the last cycle.

Also I already have wasted too much time on this errata so I won't
do further updates. Feel free to take up the ball.

> Fifth, the "if (regs->eip == addr)" check - is it helpful on 32-bit?

It avoids one fault recursion for the kernel jumping to zero.

-Andi

  reply	other threads:[~2003-10-01  7:39 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7F740D512C7C1046AB53446D3720017304AFCF@scsmsx402.sc.intel.com.suse.lists.linux.kernel>
     [not found] ` <20031001053833.GB1131@mail.shareable.org.suse.lists.linux.kernel>
     [not found]   ` <20030930224853.15073447.akpm@osdl.org.suse.lists.linux.kernel>
     [not found]     ` <20031001061348.GE1131@mail.shareable.org.suse.lists.linux.kernel>
     [not found]       ` <20030930233258.37ed9f7f.akpm@osdl.org.suse.lists.linux.kernel>
2003-10-01  6:47         ` [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch Andi Kleen
2003-10-01  7:00           ` Andrew Morton
2003-10-01  7:06             ` Andi Kleen
2003-10-01  7:31               ` Jamie Lokier
2003-10-01  7:41                 ` Andi Kleen
2003-10-01  8:02                 ` Hugh Dickins
2003-10-01  8:49                   ` Andi Kleen
2003-10-01  9:33                   ` Jamie Lokier
2003-10-01 14:51                     ` Andrew Morton
2003-10-01 14:56                       ` Andi Kleen
2003-10-01 15:19                         ` Andrew Morton
2003-10-01 15:24                           ` Andi Kleen
2003-10-01 16:18                       ` Jamie Lokier
2003-10-01  7:20           ` Jamie Lokier
2003-10-01  7:39             ` Andi Kleen [this message]
2003-10-01  8:20               ` Jamie Lokier
     [not found]         ` <20031001065705.GI1131@mail.shareable.org.suse.lists.linux.kernel>
2003-10-01  7:15           ` Andi Kleen
2003-10-01  7:24           ` Andi Kleen
2003-10-01  7:55             ` Jamie Lokier
2003-10-01  8:00               ` Andi Kleen
2003-10-01  4:30 Nakajima, Jun
2003-10-01  5:38 ` Jamie Lokier
2003-10-01  5:48   ` Andrew Morton
2003-10-01  6:13     ` Jamie Lokier
2003-10-01  6:32       ` Andrew Morton
2003-10-01  6:57         ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2003-10-01  2:23 Nakajima, Jun
2003-10-01  2:51 ` Jamie Lokier
2003-10-01  3:14   ` Andrew Morton
2003-10-01  1:54 Nakajima, Jun
2003-10-01  2:07 ` Andrew Morton
2003-10-01  2:08 ` Mike Fedyk
     [not found] <20030930073814.GA26649@mail.jlokier.co.uk.suse.lists.linux.kernel>
     [not found] ` <20030930132211.GA23333@redhat.com.suse.lists.linux.kernel>
     [not found]   ` <20030930133936.GA28876@mail.shareable.org.suse.lists.linux.kernel>
     [not found]     ` <20030930135324.GC5507@redhat.com.suse.lists.linux.kernel>
     [not found]       ` <20030930144526.GC28876@mail.shareable.org.suse.lists.linux.kernel>
     [not found]         ` <20030930150825.GD5507@redhat.com.suse.lists.linux.kernel>
     [not found]           ` <20030930165450.GF28876@mail.shareable.org.suse.lists.linux.kernel>
     [not found]             ` <20030930172618.GE5507@redhat.com.suse.lists.linux.kernel>
2003-09-30 19:08               ` Andi Kleen
2003-09-30 20:08                 ` H. Peter Anvin
2003-09-30  7:38 Jamie Lokier
2003-09-30  8:01 ` Nick Piggin
2003-09-30 13:22 ` Dave Jones
2003-09-30 13:39   ` Jamie Lokier
2003-09-30 13:53     ` Dave Jones
2003-09-30 14:45       ` Jamie Lokier
2003-09-30 15:08         ` Dave Jones
2003-09-30 16:54           ` Jamie Lokier
2003-09-30 17:26             ` Dave Jones
2003-09-30 23:55               ` Jamie Lokier
2003-10-01  0:27                 ` Andrew Morton

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=20031001073922.GL15853@wotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).