Linux PARISC architecture development
 help / color / mirror / Atom feed
From: LaMont Jones <lamont@debian.org>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
	randolph@tausq.org, parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Question about cache flushing and fork
Date: Tue, 16 Dec 2003 18:16:43 -0700	[thread overview]
Message-ID: <20031217011643.GH25535@mmjgroup.com> (raw)
In-Reply-To: <200312170057.hBH0vG4I002151@hiauly1.hia.nrc.ca>

On Tue, Dec 16, 2003 at 07:57:16PM -0500, John David Anglin wrote:
> > If we think the cache line is *smaller* than it actually is, all this
> > does is issue more flushes than necessary to the cache lines, I don't
> > understand how it results in an observable failure.
> In the particular case at hand, I noticed that calls to nested functions
> were broken on hppa64-hpux11.11.  Nested calls in GCC are done with a stack
> trampoline.  The 64-bit trampoline was in fact 72 bytes long.  GCC
> was using a line length of 32.  Because the trampoline has 16 byte alignment,
> it was possible to hit an alignment situation were the stack code didn't
> get flushed.

OK.  Note also that the sp is supposed to always be 64-byte aligned...

> After I made the GCC change, I noticed the trampoline-1.c test failed
> on a C200 but not on the A500 that I did the original fix on.  It appears
> the C200 has line length of 32 bytes.  As the C200 contains a PA 2.0
> processor, the above comment would appear incorrect.  Probably, trying
> to run a kernel built with CONFIG_PA20 defined on a C200 would fail
> because the line length specified above is *larger* than the actual
> line length.

I expect you are correct here - again, no hard knowledge of that processor
on my part.

Assuming a 32-byte cache line on a 64-byte-cache-line machine should not
cause any issues (other than performance issues, that is..)

lamont

  reply	other threads:[~2003-12-17  1:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-16  4:40 [parisc-linux] Question about cache flushing and fork Randolph Chung
2003-12-16  4:48 ` [parisc-linux] " David S. Miller
2003-12-16  4:48 ` David S. Miller
2003-12-16 15:53   ` LaMont Jones
2003-12-16 15:53   ` LaMont Jones
2003-12-16  4:56 ` Linus Torvalds
2003-12-16  4:56 ` Linus Torvalds
2003-12-16  5:06 ` [parisc-linux] " John David Anglin
2003-12-16 16:03   ` LaMont Jones
2003-12-16 22:51     ` John David Anglin
2003-12-16 23:23       ` Stan Sieler
2003-12-17  0:30       ` LaMont Jones
2003-12-17  1:03         ` Stan Sieler
2003-12-17  0:36   ` James Bottomley
2003-12-17  0:57     ` John David Anglin
2003-12-17  1:16       ` LaMont Jones [this message]
2003-12-17  1:46         ` John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
2003-12-16  4:40 Randolph Chung

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=20031217011643.GH25535@mmjgroup.com \
    --to=lamont@debian.org \
    --cc=James.Bottomley@steeleye.com \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=randolph@tausq.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