| To: | jsun@mvista.com |
|---|---|
| Subject: | Re: Linux Shared Memory Issue |
| From: | Atsushi Nemoto <nemoto@toshiba-tops.co.jp> |
| Date: | Fri, 26 Apr 2002 12:11:07 +0900 (JST) |
| Cc: | turcotte@broadcom.com, linux-mips@oss.sgi.com, mturc@broadcom.com |
| In-reply-to: | <3CC84EEC.8060100@mvista.com> |
| Organization: | TOSHIBA Personal Computer System Corporation |
| References: | <3CC72BA3.90600@mvista.com> <20020425.142518.85417141.nemoto@toshiba-tops.co.jp> <3CC84EEC.8060100@mvista.com> |
| Sender: | owner-linux-mips@oss.sgi.com |
>>>>> On Thu, 25 Apr 2002 11:46:04 -0700, Jun Sun <jsun@mvista.com> said: >> #define COLOUR_ALIGN(addr,pgoff) \ ((((addr)+SHMLBA-1)&~(SHMLBA-1)) >> + \ (((pgoff)<<PAGE_SHIFT) & (SHMLBA-1))) jsun> What is the purpose of adding the pgoff part? To avoid mapping jsun> all shared regions into the beginning of cache? I suppose so. For example, mmapping offset 0x1000 of /dev/kmem will return 0xXXXX0000 address if we ignore pgoff. This can cause aliasing problem with KSEG0 address (0x80001000). Adding pgoff, mmap will return 0xXXXX1000. In case of IPC shm, pgoff is always 0 so this change does not effect. --- Atsushi Nemoto |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Linux Shared Memory Issue, Jun Sun |
|---|---|
| Next by Date: | asm type names, Geert Uytterhoeven |
| Previous by Thread: | Re: Linux Shared Memory Issue, Jun Sun |
| Next by Thread: | XSHM/shared-pixmap fix Was: Linux Shared Memory Issue, Florian Lohoff |
| Indexes: | [Date] [Thread] [Top] [All Lists] |