From: Benjamin LaHaise <bcrl@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "David S. Miller" <davem@redhat.com>,
riel@conectiva.com.br, linux-kernel@vger.kernel.org
Subject: Re: please revert bogus patch to vmscan.c
Date: Mon, 29 Oct 2001 21:25:46 -0500 [thread overview]
Message-ID: <20011029212546.B17506@redhat.com> (raw)
In-Reply-To: <20011029.173400.35036258.davem@redhat.com> <Pine.LNX.4.33.0110291736010.7778-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0110291736010.7778-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Mon, Oct 29, 2001 at 05:42:07PM -0800
On Mon, Oct 29, 2001 at 05:42:07PM -0800, Linus Torvalds wrote:
>
> On Mon, 29 Oct 2001, David S. Miller wrote:
> >
> > I'm asking him to show the case that "breaks for something
> > else".
>
> Guys, guys, calm down.
I'm trying to be. Dave just rubs me the wrong way with his inability to
think about the problem for a minute instead of insisting on proof that
incorrect behaviour can happen. Damnit, it's supposed to be a kernel on
its way towards being more stable, not less. This is especially insulting
when you can bother to go through the work of it as a thought experiment in
less than 5 minutes to realise what could happen.
Dave: please read the above paragraph again. Now, can you see why I'm
arguing for doing the optimization in the *correct* way first? The
microbenchmark will always "prove" that avoiding the tlb flush is a win.
The test to prove that the failure case can happen is non-trivial, and
proving the real world win/loss is lengthy task involving lots of
benchmarks and effort. Please just sit down and think for 5 minutes and
acknowledge that it is a possibility!
> The difference in call frequency would, on large machines, probably be on
> the order of several magnitudes, which will certainly cut the overhead
> down to the noise while satisfying people who have architectures that can
> cache things for a long time.
>
> Agreed?
Which is exactly what was in the back of my mind in the first place. I
didn't write the patch as the distraction of going off on yet another
tangent when I'm this > < close to being done with the battle I'm currently
in just doesn't make sense. I'm sorry, but I'm not the best person for
doing a brain dump when in the middle of something, plus I assume that
people can think about the how and why of things for themselves. You'll
note that I never denied that the microoptimization in question is a win;
I fully well expect it to be. However, from the point of view of stability
we *want* to be conservative and correct. If Al had to demonstrate with
'sploits that a possible vfs race could occur every time he found one,
wouldn't he be wasting time that could be better spent finding and fixing
other problems??? Dave, please accept that other people's opinions
occasionally hold value and reconsider reacting negatively without thinking
first.
-ben
--
Fish.
next prev parent reply other threads:[~2001-10-30 2:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-29 23:08 please revert bogus patch to vmscan.c Benjamin LaHaise
2001-10-29 23:14 ` David S. Miller
2001-10-29 23:15 ` Benjamin LaHaise
2001-10-29 23:25 ` Linus Torvalds
2001-10-29 23:33 ` Benjamin LaHaise
2001-10-29 23:36 ` David S. Miller
2001-10-29 23:39 ` Benjamin LaHaise
2001-10-29 23:41 ` Linus Torvalds
2001-10-29 23:48 ` Benjamin LaHaise
2001-10-29 23:50 ` David S. Miller
2001-10-29 23:51 ` Benjamin LaHaise
2001-10-29 23:55 ` David S. Miller
2001-10-29 23:57 ` Benjamin LaHaise
2001-10-30 0:01 ` David S. Miller
2001-10-30 0:05 ` Benjamin LaHaise
2001-10-29 23:58 ` Linus Torvalds
2001-10-30 1:31 ` Rik van Riel
2001-10-30 1:34 ` David S. Miller
2001-10-30 1:42 ` Linus Torvalds
2001-10-30 1:46 ` David S. Miller
2001-10-30 2:25 ` Benjamin LaHaise [this message]
2001-10-30 15:20 ` Andrea Arcangeli
2001-10-30 15:34 ` Rik van Riel
2001-10-30 15:51 ` Andrea Arcangeli
2001-10-30 16:34 ` Benjamin LaHaise
2001-10-30 17:00 ` Andrea Arcangeli
2001-10-30 17:07 ` Rik van Riel
2001-10-30 16:13 ` Giuliano Pochini
2001-10-30 16:54 ` Andrea Arcangeli
2001-10-30 17:23 ` Giuliano Pochini
2001-10-30 17:30 ` Andrea Arcangeli
2001-10-31 0:38 ` Paul Mackerras
[not found] ` <15327.8495.767553.389519@cargo.ozlabs.ibm.com>
2001-10-31 1:57 ` Andrea Arcangeli
2001-10-30 16:38 ` Linus Torvalds
2001-10-30 16:47 ` Benjamin LaHaise
2001-10-30 16:57 ` Victor Yodaiken
2001-10-30 17:16 ` Troy Benjegerdes
2001-10-30 17:17 ` Linus Torvalds
2001-10-30 17:51 ` Victor Yodaiken
2001-10-30 18:01 ` Cort Dougan
2001-10-30 21:39 ` Paul Mackerras
2001-10-30 22:36 ` Victor Yodaiken
2001-10-30 17:23 ` Benjamin Herrenschmidt
2001-10-30 17:36 ` Benjamin Herrenschmidt
2001-10-30 17:41 ` Linus Torvalds
2001-10-30 1:49 ` Benjamin LaHaise
2001-10-30 9:03 ` Alan Cox
2001-10-29 23:22 ` Linus Torvalds
2001-10-29 23:29 ` Benjamin LaHaise
2001-10-29 23:44 ` Linus Torvalds
2001-10-30 0:02 ` Hugh Dickins
2001-10-30 0:04 ` Linus Torvalds
2001-10-30 0:04 ` David S. Miller
2001-10-29 23:51 ` Paul Mackerras
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=20011029212546.B17506@redhat.com \
--to=bcrl@redhat.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=torvalds@transmeta.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