From: Valdis.Kletnieks@vt.edu
To: Linus Torvalds <torvalds@osdl.org>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: -mregparm=3 (was Re: [PATCH] i386 do_machine_check() is redundant.
Date: Mon, 29 Sep 2003 15:54:48 -0400 [thread overview]
Message-ID: <200309291954.h8TJsm6p002210@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Mon, 29 Sep 2003 11:46:12 PDT." <Pine.LNX.4.44.0309291142430.3626-100000@home.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
On Mon, 29 Sep 2003 11:46:12 PDT, Linus Torvalds said:
> Has anybody checked out whether the kernel works with -mregparm=3? I
> forget who did a lot of the work on it originally, and it certainly _used_
> to work fine. The improvements to both code size and performance were, if
> I remember correctly, measurable but not huge.
It works well enough that my laptop made it to initlevel 3. The code size
wasn't drastically smaller (perhaps another 2-3% but I already compile with
-Os). The system "felt" snappier, but I have no benchmark numbers to give. I
could probably get some numbers if anybody cares, but there's a showstopper for
me - I can't make it to initlevel 5 easily:
> One worry (apart from just broken compilers and missing "asmlinkage"
> annotations) is that having compiler-version-dependent calling conventions
> makes for another variable to take into account when chasing down bugs and
> worrying about things like the Nvidia module etc. So it's probably not
> worth doing unless the advantages are clear.
Quite correct - even after recompiling the sourced portions of the NVidia
driver, it dies a horrid death on 'insmod' when the closed-source portion
passes a parameter on the stack and the open side expects the value in a
register, and follows the register value to a quick death....
Yes, yes, I know, I could re-try with the open-source nv driver instead of the
closed-source NVidia driver - but the open-source one costs me more in
performance (as it's unaccelerated) than the mregparm=3 is likely to get me
back....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
next prev parent reply other threads:[~2003-09-29 19:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-28 16:29 [PATCH] i386 do_machine_check() is redundant Brian Gerst
2003-09-28 18:24 ` Linus Torvalds
2003-09-28 18:30 ` Brian Gerst
2003-09-28 18:34 ` Linus Torvalds
2003-09-28 18:44 ` Brian Gerst
2003-09-28 19:04 ` Arjan van de Ven
2003-09-29 18:46 ` Linus Torvalds
2003-09-29 19:23 ` Jeff Garzik
2003-09-29 19:54 ` Valdis.Kletnieks [this message]
2003-09-30 8:28 ` -mregparm=3 (was " Helge Hafting
2003-09-30 15:29 ` Valdis.Kletnieks
2003-09-30 15:48 ` Linus Torvalds
2003-09-29 20:20 ` Mikulas Patocka
2003-09-29 20:26 ` Daniel Jacobowitz
2003-09-29 21:36 ` Mikulas Patocka
2003-09-29 21:40 ` Daniel Jacobowitz
2003-09-29 21:43 ` Mikulas Patocka
2003-09-29 21:48 ` Jakub Jelinek
2003-09-30 0:24 ` Jamie Lokier
2003-09-30 4:49 ` Valdis.Kletnieks
2003-09-30 4:55 ` Robert Love
2003-09-30 14:37 ` Valdis.Kletnieks
2003-09-30 15:48 ` Robert Love
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=200309291954.h8TJsm6p002210@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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).