From: kuznet@ms2.inr.ac.ru
To: torvalds@transmeta.COM (Linus Torvalds)
Cc: linux-kernel@vger.kernel.org
Subject: Re: VM-related Oops: 2.4.15pre1
Date: Mon, 19 Nov 2001 21:40:41 +0300 (MSK) [thread overview]
Message-ID: <200111191840.VAA21046@ms2.inr.ac.ru> (raw)
In-Reply-To: <Pine.LNX.4.33.0111181820040.7500-100000@penguin.transmeta.com> from "Linus Torvalds" at Nov 19, 1 05:45:00 am
Hello!
> Oh, and I bet TCP would break horribly if gcc wrote internal temporary
> values to the socket sequence numbers.
Actually tcp does not depend on gcc idiosyncrasies. It works under
socket lock.
Well, all these things sort of read-copy updates, relying on memory
ordering etc. may be very good, but:
- I do not know the rules of the game.
- Nobody seems to knows them.
- Anyway, I do not have enough of brain cells to keep this under control.
So, networking relies only on explicit locks and barriers and gcc may do
everything except for splitting "optimizations" of this kind over barriers.
The most dangerous thing, which could harm 2.2 a lot is intuitively
natural:
static int a;
auto int b;
b = a;
do_something_with_b;
Goal of this code is clear, to get snapshot of "a"
and to do anything with "b", assuming it does not change.
In 2.2 we rely on this in many places.
I do not see anything which could prohibit gcc to eliminate register
allocated for "b" while CSE and to use "a" directly f.e. when b does
not fit to hardware register set in any case. Actually, gcc
does not make this to our luck, but I suspect it is only because
it is too stupid.
Alexey
next prev parent reply other threads:[~2001-11-19 18:41 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 22:23 Simon Kirby
2001-11-17 22:53 ` Christian Ehrhardt
2001-11-18 3:12 ` Linus Torvalds
2001-11-18 4:10 ` Andrea Arcangeli
2001-11-18 6:24 ` Linus Torvalds
2001-11-18 6:37 ` Andrea Arcangeli
2001-11-18 7:31 ` Linus Torvalds
2001-11-18 12:05 ` Alan Cox
2001-11-19 2:02 ` Linus Torvalds
2001-11-19 2:27 ` Linus Torvalds
2001-11-19 18:40 ` kuznet [this message]
2001-11-19 10:15 ` Alan Cox
2001-11-19 16:39 ` Linus Torvalds
2001-11-19 18:03 ` Eric W. Biederman
2001-11-19 19:04 ` Linus Torvalds
2001-11-19 23:52 ` John Alvord
2001-11-21 2:31 ` Pavel Machek
[not found] ` <200111180731.fAI7VFa01371@penguin.transmeta.com>
2001-11-18 7:51 ` Andrea Arcangeli
2001-11-18 17:10 ` Horst von Brand
2001-11-19 2:04 ` Linus Torvalds
2001-11-19 3:22 ` Jeff V. Merkey
2001-11-19 8:44 ` David Woodhouse
2001-11-19 16:57 ` Linus Torvalds
2001-11-19 17:56 ` Simon Kirby
2001-11-19 18:03 ` Linus Torvalds
2001-11-19 18:31 ` Simon Kirby
2001-11-19 20:01 ` Marcelo Tosatti
2001-11-19 21:26 ` Linus Torvalds
2001-11-19 21:49 ` Rik van Riel
2001-11-19 22:40 ` Linus Torvalds
2001-11-19 22:59 ` Rik van Riel
2001-11-19 23:03 ` Linus Torvalds
2001-11-20 0:06 ` Rik van Riel
2001-11-20 0:08 ` Linus Torvalds
2001-11-20 0:27 ` Rik van Riel
2001-11-19 23:27 ` Simon Kirby
2001-11-19 23:38 ` Linus Torvalds
2001-11-19 23:52 ` Simon Kirby
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=200111191840.VAA21046@ms2.inr.ac.ru \
--to=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®