All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: AA's 00_backout_gcc_3-0-patch-1
Date: Tue, 27 May 2003 00:54:45 +0200	[thread overview]
Message-ID: <20030526225445.GV3767@dualathlon.random> (raw)
In-Reply-To: <Pine.LNX.4.55L.0305261929460.30175@freak.distro.conectiva>

On Mon, May 26, 2003 at 07:30:44PM -0300, Marcelo Tosatti wrote:
> 
> Andrea,
> 
> For what reason are you doing this?

yes, if you ask the gcc developers any piece of memory that will change
under gcc, despite gcc has no clue that it can change under it, MUST (in
RFC sense) be marked volatile.

this avoids possible crashes for example with a switch(xtime.tv_sec)
case 0,1,2,3,4 etc.. gcc could generate an hash to get the cases fast and
verify the xtime.tv_sec is <= 4 before derferencing tv_sec again. But
tv_sec could change under gcc and it would jump to random.

However with xtime itself, it would be very rare to get failures like
the above, we're not going to compare xtime that often in a gcc-crashing
way.

Still xtime is one obvious target for being marked volatile, and for
correctness I like it. Performance shouldn't matter.

Overall in kernel we disagreed to follow the MUST requrested by the gcc
developers, we often want to do comparisons of variables out of locks to
know if we need to take the lock and work on a garbage collection or
stuff like that and we for sure don't want to mark those variables
volatile since they must be cached and not spilled all the time, under
the locks. Linus as well was against using volatile for every piece of
memory that can change under gcc. The decision is been basically to
outsmart gcc in choosing if gcc has rights to generate kernel crashing
code or not. This makes kernel developement even more difficult since
you've to imagine whatever smart thing gcc can do with your not
serialized code to know if you're forced to mark the stuff volatile, but
it'll generate the very best performance.

As for xtime since it won't hurt performance, and since it's an obvious
volatile candidate I preferred to take the obviously safe approch. I
prefer to take the outsmart-gcc-optimizations way, only when it is
worthwhile.

> 
> diff -urN 2.4.6pre3/kernel/timer.c backoutgcc/kernel/timer.c
> --- 2.4.6pre3/kernel/timer.c	Wed Jun 13 04:02:52 2001
> +++ backoutgcc/kernel/timer.c	Wed Jun 13 15:49:13 2001
> @@ -32,7 +32,7 @@
>  long tick = (1000000 + HZ/2) / HZ;	/* timer interrupt period */
> 
>  /* The current time */
> -struct timeval xtime __attribute__ ((aligned (16)));
> +volatile struct timeval xtime __attribute__ ((aligned (16)));
> 
>  /* Don't completely fail for HZ > 500.  */
>  int tickadj = 500/HZ ? : 1;		/* microsecs */
> 


Andrea

  reply	other threads:[~2003-05-26 22:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-26 22:30 AA's 00_backout_gcc_3-0-patch-1 Marcelo Tosatti
2003-05-26 22:54 ` Andrea Arcangeli [this message]
2003-05-26 23:15   ` J.A. Magallon
2003-05-26 23:30     ` Andrea Arcangeli

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=20030526225445.GV3767@dualathlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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.