From: Matt Mackall <mpm@selenic.com> To: William Lee Irwin III <wli@holomorphy.com>, Thomas Schlichter <schlicht@uni-mannheim.de>, Piet Delaney <piet@www.piet.net>, Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Date: Fri, 11 Jul 2003 09:56:30 -0500 [thread overview] Message-ID: <20030711145630.GL27280@waste.org> (raw) In-Reply-To: <20030710103022.GV15452@holomorphy.com> On Thu, Jul 10, 2003 at 03:30:22AM -0700, William Lee Irwin III wrote: > On Thursday 10 July 2003 11:48, William Lee Irwin III wrote: > > It's not the 64B... > > I care about the unneeded but executed code! > > But I'm a hopeless perfectionist caring about such nits... > > On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote: > > And I don't know why everybody hates my patches... ;-( > > It's not that anyone hates them, it's that > pass 1: the semantics (0 == empty cpu set) needed preserving > pass 2: remove code instead of changing redundant stuff > > NFI YTF gcc doesn't optimize out the whole shebang. Probably would if inline were added to the function spec? If we're going to worry about space, we'd start by worrying about the existence of current->cpus_allowed in the UP case. > At any rate, if we're pounding APM BIOS calls or apm_power_off() > like wild monkeys there's something far more disturbing going wrong > than 64B of code gcc couldn't optimize (it's probably due to some > jump target being aligned to death or some such nonsense). I much prefer the removal of #ifdef approach - would have prevented the bug getting out in the first place. -- Matt Mackall : http://www.selenic.com : of or relating to the moon
WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com> To: William Lee Irwin III <wli@holomorphy.com>, Thomas Schlichter <schlicht@uni-mannheim.de>, Piet Delaney <piet@www.piet.net>, Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Date: Fri, 11 Jul 2003 09:56:30 -0500 [thread overview] Message-ID: <20030711145630.GL27280@waste.org> (raw) In-Reply-To: <20030710103022.GV15452@holomorphy.com> On Thu, Jul 10, 2003 at 03:30:22AM -0700, William Lee Irwin III wrote: > On Thursday 10 July 2003 11:48, William Lee Irwin III wrote: > > It's not the 64B... > > I care about the unneeded but executed code! > > But I'm a hopeless perfectionist caring about such nits... > > On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote: > > And I don't know why everybody hates my patches... ;-( > > It's not that anyone hates them, it's that > pass 1: the semantics (0 == empty cpu set) needed preserving > pass 2: remove code instead of changing redundant stuff > > NFI YTF gcc doesn't optimize out the whole shebang. Probably would if inline were added to the function spec? If we're going to worry about space, we'd start by worrying about the existence of current->cpus_allowed in the UP case. > At any rate, if we're pounding APM BIOS calls or apm_power_off() > like wild monkeys there's something far more disturbing going wrong > than 64B of code gcc couldn't optimize (it's probably due to some > jump target being aligned to death or some such nonsense). I much prefer the removal of #ifdef approach - would have prevented the bug getting out in the first place. -- Matt Mackall : http://www.selenic.com : of or relating to the moon -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2003-07-11 14:42 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-09 5:35 2.5.74-mm3 Andrew Morton 2003-07-09 5:35 ` 2.5.74-mm3 Andrew Morton 2003-07-09 9:05 ` 2.5.74-mm3 Thomas Schlichter 2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton 2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton 2003-07-09 9:25 ` 2.5.74-mm3 Thomas Schlichter 2003-07-09 9:25 ` 2.5.74-mm3 Thomas Schlichter 2003-07-09 9:38 ` 2.5.74-mm3 Marc-Christian Petersen 2003-07-09 11:23 ` 2.5.74-mm3 Jan De Luyck 2003-07-09 11:23 ` 2.5.74-mm3 Jan De Luyck 2003-07-09 13:23 ` 2.5.74-mm3 Ramón Rey Vicente 2003-07-10 5:44 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Piet Delaney 2003-07-10 5:44 ` Piet Delaney 2003-07-10 6:08 ` William Lee Irwin III 2003-07-10 6:08 ` William Lee Irwin III 2003-07-10 7:10 ` William Lee Irwin III 2003-07-10 7:10 ` William Lee Irwin III 2003-07-10 7:18 ` Andrew Morton 2003-07-10 7:18 ` Andrew Morton 2003-07-10 7:59 ` William Lee Irwin III 2003-07-10 7:59 ` William Lee Irwin III 2003-07-10 4:09 ` hptraid.o -- No array found? Seth Chromick 2003-07-10 12:20 ` Alan Cox 2003-07-10 8:15 ` 2.5.74-mm3 - module-init-tools: necessary to replace root copies? Piet Delaney 2003-07-10 8:15 ` Piet Delaney 2003-07-10 8:15 ` Piet Delaney 2003-07-10 8:15 ` Piet Delaney 2003-07-10 8:23 ` Andrew Morton 2003-07-10 8:23 ` Andrew Morton 2003-07-10 9:22 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Thomas Schlichter 2003-07-10 9:22 ` Thomas Schlichter 2003-07-10 9:27 ` William Lee Irwin III 2003-07-10 9:27 ` William Lee Irwin III 2003-07-10 9:42 ` Thomas Schlichter 2003-07-10 9:42 ` Thomas Schlichter 2003-07-10 9:48 ` William Lee Irwin III 2003-07-10 9:48 ` William Lee Irwin III 2003-07-10 9:59 ` Thomas Schlichter 2003-07-10 9:59 ` Thomas Schlichter 2003-07-10 10:30 ` William Lee Irwin III 2003-07-10 10:30 ` William Lee Irwin III 2003-07-10 10:49 ` Thomas Schlichter 2003-07-10 10:49 ` Thomas Schlichter 2003-07-11 14:56 ` Matt Mackall [this message] 2003-07-11 14:56 ` Matt Mackall 2003-07-09 9:24 ` 2.5.74-mm3 Matt Mackall 2003-07-09 9:24 ` 2.5.74-mm3 Matt Mackall 2003-07-09 9:29 ` 2.5.74-mm3 William Lee Irwin III 2003-07-09 9:29 ` 2.5.74-mm3 William Lee Irwin III 2003-07-10 18:21 ` 2.5.74-mm3 Valdis.Kletnieks 2003-07-11 8:25 ` 2.5.74-mm3 Joe Thornber 2003-07-11 8:25 ` 2.5.74-mm3 Joe Thornber 2003-07-11 16:02 ` 2.5.74-mm3 Anton Blanchard 2003-07-11 16:02 ` 2.5.74-mm3 Anton Blanchard
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=20030711145630.GL27280@waste.org \ --to=mpm@selenic.com \ --cc=akpm@osdl.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=piet@www.piet.net \ --cc=schlicht@uni-mannheim.de \ --cc=wli@holomorphy.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: linkBe 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.