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
next prev parent 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