From: Andrew Morton <akpm@zip.com.au>
To: Dave Jones <davej@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [patch] Prefetching file_read_actor()
Date: Sun, 30 Dec 2001 21:44:15 -0800 [thread overview]
Message-ID: <3C2FFB2F.D02095A2@zip.com.au> (raw)
In-Reply-To: <20011231033220.A1686@suse.de>
Dave Jones wrote:
>
> After noticing file_read_actor() showing up in profiles quite
> a bit, I grepped old l-k messages, and turned up a post by
> Manfred Spraul in which he posted a patch using inline asm
> to prefetch read data. This was x86 specific in generic code,
> so was a little hackish..
> Now that we have the prefetch macros, I decided to play with
> this a little tonight, and came up with this patch..
Well I don't know diddly about the prefetch instruction, but.
> ...
> +
> + if (size > 128) {
> + int i;
> + for(i=0; i<size; i+=64) {
> + prefetch (kaddr+offset);
> + prefetch (kaddr+offset+(L1_CACHE_BYTES*2));
> + }
> + }
> +
> left = __copy_to_user(desc->buf, kaddr + offset, size);
> kunmap(page);
>
This needs to be inside ARCH_HAS_PREFETCH. Otherwise, for
architectures which do not implement prefetch, we have
for (i = 0; i < size; i += 64) {
{;}
{;}
}
and the compiler will *not* optimise this away. The compiler deliberately
leaves this construct alone because it assumes the programmer is asking for
a busywait loop.
We shouldn't add a busywait loop to file_read_actor(), yes?
<ot>
Reminds me of a version of the Microsoft C compiler back in about '85 which
"optimise" away
for ( ; ; )
;
Completely.
</ot>
Is prefetching 4k at a time optimal? Should the prefetch be embedded
in copy_*_user?
The code assumes that L1_CACHE_BYTES equates to the prefetch chunk.
Is this reasonable, or should it be abstracted out to a new PREFETCH_BYTES?
That `64' needs to be PREFETCH_BYTES * 2 or L1_CACHE_BYTES * 2, yes?
How come the code keeps prefetching the same address? Shouldn't
we be adding `i' to the address in there?
The code makes no attempt to align the prefetch address to anything.
Should it?
What happens if a prefetch spills over the end of the page and
faults?
> Comments ?
That'll do for now :)
-
next prev parent reply other threads:[~2001-12-31 5:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-31 3:32 [patch] Prefetching file_read_actor() Dave Jones
2001-12-31 5:44 ` Andrew Morton [this message]
2001-12-31 10:58 ` Manfred Spraul
2001-12-31 19:28 ` Andrew Morton
2001-12-31 19:47 ` Dave Jones
2001-12-31 20:40 ` Ryan Cumming
2002-01-01 10:29 ` Alan Cox
2002-01-01 12:45 ` Dave Jones
2002-01-01 15:26 ` Alan Cox
2002-01-01 10:30 ` Alan Cox
2002-01-01 11:08 ` Anton Blanchard
2001-12-31 20:31 ` Dave Jones
2001-12-31 13:00 ` Alan Cox
2001-12-31 12:50 ` Rik van Riel
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=3C2FFB2F.D02095A2@zip.com.au \
--to=akpm@zip.com.au \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
/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