From: Jamie Lokier <jamie@shareable.org>
To: Andi Kleen <ak@suse.de>
Cc: 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 08:20:11 +0100 [thread overview]
Message-ID: <20031001072011.GJ1131@mail.shareable.org> (raw)
In-Reply-To: <p73k77pzc69.fsf@oldwotan.suse.de>
Andi Kleen wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
> > Looking at Andi's patch, it is also a dead box if the fault happens inside
> > down_write(mmap_sem). That should be fixed, methinks.
>
> The only way to fix all that would be to move the instruction checks early
> into the fast path.
>
> [On a P4 the overhead is 3.7268 vs 3.6594 microseconds for a fault that
> doesn't hit as measured by lmbench2's lat_sig. This was before the latest
> changes which added more checking, so the overhead is probably bigger now]
Hi Andi!
I think the mmap_sem problems are fixed by an appropriate "address >=
TASK_SIZE" check at the beginning do_page_fault, which should jump
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 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.
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().
Third, once you have taken the "limit" variable idea from my patch,
clamp that at "instr + 14", and so remove the small amount of loop
setup and iteration overhead which is there to restrict the
instruction to 15 bytes. Build it in to the other limit check.
Fourth, without a switch statement that's no need for a scan_more
variable. Setting a boolean variable in one place to test it on
another is still surprisingly poor with GCC - it doesn't remove the
variable and turn the code into direct jumps as you'd think, much of
the time. Just test the bit vector and if it's zero, return 0,
otherwise carry on to check if the byte is 0x0f, and if not, loop.
Fifth, the "if (regs->eip == addr)" check - is it helpful on 32-bit?
Thoughts for the day,
-- Jamie
next prev parent reply other threads:[~2003-10-01 7:20 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 [this message]
2003-10-01 7:39 ` Andi Kleen
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=20031001072011.GJ1131@mail.shareable.org \
--to=jamie@shareable.org \
--cc=ak@suse.de \
--cc=akpm@osdl.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