[parisc-linux] Question about cache flushing and fork

[John David Anglin]

> 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.

I changed the length to 64 on hppa64 to fix this problem.  I based this
on the following code in include/parisc/cache.h:

/*
 * PA 2.0 processors have 64-byte cachelines; PA 1.1 processors have
 * 32-byte cachelines.  The default configuration is not for SMP anyway,
 * so if you're building for SMP, you should select the appropriate
 * processor type.  There is a potential livelock danger when running
 * a machine with this value set too small, but it's more probable you'll
 * just ruin performance.
 */
#ifdef CONFIG_PA20
#define L1_CACHE_BYTES 64
#else
#define L1_CACHE_BYTES 32
#endif

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.  On the otherhand, PDC_CACHE allows setting some cache
parameters.

Dave
-- 
J. David Anglin                                  dave.anglin at nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)