LTP testing (shmat01)

LTP testing (shmat01)

[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 ?

/Carsten


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: LTP testing (shmat01)

[Ralf Baechle]

On Thu, Jul 04, 2002 at 05:26:28PM +0200, Carsten Langgaard wrote:

> 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

Re: LTP testing (shmat01)

[Carsten Langgaard]

Ralf Baechle wrote:

> On Thu, Jul 04, 2002 at 05:26:28PM +0200, Carsten Langgaard wrote:
>
> > 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 ?

>
>   Ralf

Re: LTP testing (shmat01)

[Ralf Baechle]

On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote:

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

Re: LTP testing (shmat01)

[Carsten Langgaard]

Ralf Baechle wrote:

> On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote:
>
> > > 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.

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.

>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: LTP testing (shmat01)

[Ralf Baechle]

On Fri, Jul 05, 2002 at 08:30:48AM +0200, Carsten Langgaard wrote:

> 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

Re: LTP testing (shmat01)

[Jun Sun]

Ralf Baechle wrote:

> On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote:
> 
> 
>>>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.
> 


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

Re: LTP testing (shmat01)

[Ralf Baechle]

On Mon, Jul 08, 2002 at 10:31:23AM -0700, Jun Sun wrote:

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

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

> 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

Re: LTP testing (shmat01)

[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


Ralf Baechle wrote:

> On Mon, Jul 08, 2002 at 10:31:23AM -0700, Jun Sun wrote:
>
> > 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 ...
>
> > 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.
>
> > 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

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

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote:
> 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.

[-- Attachment #2: glibc-mips-shm.patch --]
[-- Type: text/plain, Size: 2327 bytes --]

2002-07-08  H.J. Lu  <hjl@gnu.org>

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

--- sysdeps/unix/sysv/linux/mips/sys/shm.h.mips	Mon Jul  8 11:27:12 2002
+++ sysdeps/unix/sysv/linux/mips/sys/shm.h	Mon Jul  8 11:27:06 2002
@@ -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 */

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

[Ralf Baechle]

On Mon, Jul 08, 2002 at 11:29:03AM -0700, H. J. Lu wrote:

> How about this patch?

Yes, please apply.

  Ralf

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

[Carsten Langgaard]

Looks fine to me.
Thanks
/Carsten


"H. J. Lu" wrote:

> On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote:
> > 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.
>
>   ------------------------------------------------------------------------
>
>    glibc-mips-shm.patchName: glibc-mips-shm.patch
>                        Type: Plain Text (text/plain)

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

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

[Andreas Jaeger]

thanks, committed to both mainline and glibc 2.2,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

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

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Mon, 2002-07-08 at 11:29, H. J. Lu wrote:
> On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote:
> > 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.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]