Skip to contentSkip to conversation

LTP testing (shmat01)

DISCUSSION Carsten Langgaard 6 participants 14 messages Jul 4, 2002 – Jul 10, 2002 MIPS

lore
Share & tools
lore

Carsten Langgaard

author
#0 lore raw

The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 (in include/asm-mips/shmparam.h).
For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone know why we are different ?

/Carsten

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com
#1 lore raw
Quoted 4 lines · Carsten Langgaard

The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 (in include/asm-mips/shmparam.h).
For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone know why we are different ?

Sounds like a broken test. The value of SHMLBA is ABI mandated. Technically we could use any power of 2 >= 32kB easily and with plenty of headache any power of 2 > PAGE_SIZE.

Ralf

author
#2 lore raw
Quoted 10 lines · Ralf Baechle
Quoted 4 lines · Carsten Langgaard

The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 (in include/asm-mips/shmparam.h).
For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone know why we are different ?

Sounds like a broken test. The value of SHMLBA is ABI mandated. Technically we could use any power of 2 >= 32kB easily and with plenty of headache any power of 2 > PAGE_SIZE.

Ok, I see, but is there any reason for us to be different than the rest of the world ?

Quoted 2 lines

Ralf

#3 lore raw
Quoted 4 lines · Carsten Langgaard
Quoted 1 line

any power of 2 > PAGE_SIZE.

Ok, I see, but is there any reason for us to be different than the rest of the world ?

Imho the your question already wrong :-) Any assumption about the constant's value in a piece of code is wrong.

The reason why the constant's value was choosen are virtually indexed caches. The value allows attaching of shared memory segment without any cache flushes.

Other architectures also use different values from PAGE_SIZE like IA64 1MB, SH 16kB and Sparc not even a constant value accross all architectures variants, so unlike what your posting implicates we're not that unusual.

Ralf

author
#4 lore raw
Quoted 10 lines · Ralf Baechle
Quoted 4 lines · Carsten Langgaard
Quoted 1 line

any power of 2 > PAGE_SIZE.

Ok, I see, but is there any reason for us to be different than the rest of the world ?

Imho the your question already wrong :-) Any assumption about the constant's value in a piece of code is wrong.

Quoted 7 lines

The reason why the constant's value was choosen are virtually indexed caches. The value allows attaching of shared memory segment without any cache flushes.

Other architectures also use different values from PAGE_SIZE like IA64 1MB, SH 16kB and Sparc not even a constant value accross all architectures variants, so unlike what your posting implicates we're not that unusual.

Using PAGE_SIZE is ok, even though it may differ from different architecture, because SHMLBA is defined as the following in /usr/include/sys/shm.h:
#define SHMLBA (__getpagesize ())

So I would expect the user application and the kernel should have the same idea of what the size is.

Quoted 1 line

Ralf

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com
#5 lore raw
Quoted 6 lines · Carsten Langgaard

Using PAGE_SIZE is ok, even though it may differ from different architecture, because SHMLBA is defined as the following in /usr/include/sys/shm.h:
#define SHMLBA (__getpagesize ())

So I would expect the user application and the kernel should have the same idea of what the size is.

Definately. I just checked it - this is an antique bug that was already present in glibc 2.0.6. I'm amazed people we got away with that one for so long ...

Ralf

#6 lore raw
In reply to Ralf Baechle
Quoted 9 lines · Ralf Baechle
Quoted 5 lines · Carsten Langgaard
Quoted 2 lines

any power of 2 > PAGE_SIZE.

Ok, I see, but is there any reason for us to be different than the rest of the world ?

Quoted 7 lines

Imho the your question already wrong :-) Any assumption about the constant's value in a piece of code is wrong.

The reason why the constant's value was choosen are virtually indexed caches. The value allows attaching of shared memory segment without any cache flushes.

I think this is also an effective way to avoid cache aliasing. As long as your cache size is less than 256K, you don't get cache aliasing through shared memory. Perhaps other arches don't have cache aliasing? I know for sure i386 does not have that effect.

Jun

#7 lore raw
Quoted 1 line · Jun Sun

I think this is also an effective way to avoid cache aliasing.

Correct. At the same time the choice of this value also tends to cause bad use of L2 caches ...

Quoted 2 lines

As long as your cache size is less than 256K, you don't get cache aliasing through shared memory.

Actually the "alias set" has to be less than 256kB. On existing MIPS implementations it's at most 16kB; a sillyness of the R4000 / R4400 VCE exceptions makes a value of 32kB mandatory for poerformance reasons.

Quoted 2 lines

Perhaps other arches don't have cache aliasing? I know for sure i386 does not have that effect.

The problem doesn't exist on physically indexed caches. Also on read-only caches such as the instruction cache it usually can be ignored. So for example the R2000, R3000, SB1 cores, RM7000, R4kc and R5kc in the right configurations and the R10000 family don't suffer from aliases. Details are messy :)

Ralf

author
#8 lore raw

I have no preferences of the value of SHMLBA, as long as the define in /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync.

/Carsten

Quoted 24 lines · Ralf Baechle
Quoted 1 line · Jun Sun

I think this is also an effective way to avoid cache aliasing.

Correct. At the same time the choice of this value also tends to cause bad use of L2 caches ...

Quoted 2 lines

As long as your cache size is less than 256K, you don't get cache aliasing through shared memory.

Actually the "alias set" has to be less than 256kB. On existing MIPS implementations it's at most 16kB; a sillyness of the R4000 / R4400 VCE exceptions makes a value of 32kB mandatory for poerformance reasons.

Quoted 2 lines

Perhaps other arches don't have cache aliasing? I know for sure i386 does not have that effect.

The problem doesn't exist on physically indexed caches. Also on read-only caches such as the instruction cache it usually can be ignored. So for example the R2000, R3000, SB1 cores, RM7000, R4kc and R5kc in the right configurations and the R10000 family don't suffer from aliases. Details are messy :)

Ralf

#9 lore raw

PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01))

Quoted 5 lines · Carsten Langgaard

I have no preferences of the value of SHMLBA, as long as the define in /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync.

/Carsten

How about this patch?

H.J.

2002-07-08 H.J. Lu <[email protected]>

* sysdeps/unix/sysv/linux/mips/sys/shm.h: New.

unix/sysv/linux/mips/sys/shm.h renamed from unix/sysv/linux/mips/sys/shm.h.mips +67 -0
@@ -0,0 +1,67 @@
+/* Copyright (C) 2002 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef _SYS_SHM_H
+#define _SYS_SHM_H	1
+
+#include <features.h>
+
+#define __need_size_t
+#include <stddef.h>
+
+/* Get common definition of System V style IPC.  */
+#include <sys/ipc.h>
+
+/* Get system dependent definition of `struct shmid_ds' and more.  */
+#include <bits/shm.h>
+
+/* Define types required by the standard.  */
+#define __need_time_t
+#include <time.h>
+
+#ifdef __USE_XOPEN
+# ifndef __pid_t_defined
+typedef __pid_t pid_t;
+#  define __pid_t_defined
+# endif
+#endif	/* X/Open */
+
+__BEGIN_DECLS
+
+/* Segment low boundary address multiple.  */
+#define SHMLBA	0x40000
+
+/* The following System V style IPC functions implement a shared memory
+   facility.  The definition is found in XPG4.2.  */
+
+/* Shared memory control operation.  */
+extern int shmctl (int __shmid, int __cmd, struct shmid_ds *__buf) __THROW;
+
+/* Get shared memory segment.  */
+extern int shmget (key_t __key, size_t __size, int __shmflg) __THROW;
+
+/* Attach shared memory segment.  */
+extern void *shmat (int __shmid, __const void *__shmaddr, int __shmflg)
+     __THROW;
+
+/* Detach shared memory segment.  */
+extern int shmdt (__const void *__shmaddr) __THROW;
+
+__END_DECLS
+
+#endif /* sys/shm.h */
#10 lore raw

Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01))

Quoted 1 line · H. J. Lu

How about this patch?

Yes, please apply.

Ralf

author
#11 lore raw

Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01))

In reply to H. J. Lu

Looks fine to me.
Thanks
/Carsten

Quoted 7 lines · H. J. Lu
Quoted 5 lines · Carsten Langgaard

I have no preferences of the value of SHMLBA, as long as the define in /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync.

/Carsten

Quoted 8 lines

How about this patch?

H.J.

------------------------------------------------------------------------

glibc-mips-shm.patchName: glibc-mips-shm.patch
Type: Plain Text (text/plain)

--

_    _ ____  ___   Carsten Langgaard   Mailto:[email protected]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com
#13 lore raw

Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01))

In reply to H. J. Lu
Quoted 8 lines · H. J. Lu
Quoted 5 lines · Carsten Langgaard

I have no preferences of the value of SHMLBA, as long as the define in /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync.

/Carsten

How about this patch?

No. As Roland said, define SHMLBA in the mips bits/shm.h file and change sys/shm.h to define SHMLBA only if it wasn't defined before.

Signature · 3 lines
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------