From: Tom Leete <tleete@mountain.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Ford <david@linux.com>, Stephen Frost <sfrost@snowman.net>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.x and SMP fails to compile (`current' undefined)
Date: Thu, 01 Feb 2001 02:52:15 -0500 [thread overview]
Message-ID: <3A7915AF.5C9C54CF@mountain.net> (raw)
In-Reply-To: <E14NxKP-0002KH-00@the-village.bc.nu>
Alan Cox wrote:
>
> > It's not an incompatibility with the k7 chip, just bad code in
> > include/asm-i386/string.h. in_interrupt() cannot be called from there.
>
> The string.h code was fine, someone came along and put in a ridiculous loop
> in the include dependancies and broke it. Nobody has had the time to untangle
> it cleanly since
Yes, bitrot. I don't see a rearrangement of system headers happening in 2.4.
I'm pretty sure if I committed such a patch it would have no measurable
lifetime.
>
> > I have posted a patch here many times since last May. Most recent was
> > Saturday.
>
> uninlining the code is too high a cost.
I question that. Athlon does branch prediction on call targets, function
calls are cheap. 3dnow saves 25%-50% of cycles on a copy. How many function
calls can be paid for with 1000 cycles or so?
My patch still inlines the standard string const_memcpy for the case of
small known length.
If I configure SMP for a UP box, performance is clearly not my first
concern. If I have a real SMP Athlon system, performance should not improve
by only using one processor.
How about we get it to build before we optimize it?
Regards,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-02-01 7:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-31 2:53 2.4.x and SMP fails to compile (`current' undefined) David Ford
2001-01-31 3:01 ` Stephen Frost
2001-01-31 4:37 ` David Ford
2001-01-31 7:16 ` Peter Samuelson
2001-01-31 8:03 ` Tom Leete
2001-01-31 10:26 ` Peter Samuelson
2001-01-31 10:48 ` Tom Leete
2001-01-31 11:10 ` Peter Samuelson
2001-01-31 23:01 ` Olaf Titz
2001-01-31 23:38 ` David Lang
2001-02-01 1:11 ` Peter Samuelson
2001-02-01 1:22 ` Alan Cox
2001-02-02 15:12 ` Pavel Machek
2001-01-31 13:29 ` Alan Cox
2001-02-01 7:52 ` Tom Leete [this message]
2001-02-01 8:12 ` Andre Hedrick
2001-02-01 13:39 ` Tom Leete
2001-02-01 10:50 ` Alan Cox
2001-02-01 13:53 ` Tom Leete
2001-01-31 23:26 ` David Lang
2001-02-01 15:04 ` Jeff Garzik
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=3A7915AF.5C9C54CF@mountain.net \
--to=tleete@mountain.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sfrost@snowman.net \
/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.