From: Keith O. <ka...@oc...> - 2002-04-11 22:38:32
|
On Thu, 11 Apr 2002 12:08:33 +0200, Daniel Phillips <phi...@bo...> wrote: > >Heads up: ->virtual may be eliminated in 2.5, except for config_highmem. #define WANT_PAGE_VIRTUAL. AFAIK it is required for sparc64 so I doubt it will disappear. 2.5.8-pre3 include/linux/mm.h checks #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) |
From: Keith O. <ka...@oc...> - 2002-04-12 00:47:22
|
On Thu, 11 Apr 2002 16:18:37 +0200, Daniel Phillips <phi...@bo...> wrote: >On April 12, 2002 12:38 am, Keith Owens wrote: >> On Thu, 11 Apr 2002 12:08:33 +0200, >> Daniel Phillips <phi...@bo...> wrote: >> > >> >Heads up: ->virtual may be eliminated in 2.5, except for config_highmem. >> >> #define WANT_PAGE_VIRTUAL. AFAIK it is required for sparc64 so I doubt >> it will disappear. >> >> 2.5.8-pre3 include/linux/mm.h checks >> #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) > >OK, fine. Out of interest, why is this something sparc64 can't do without? include/asm-sparc64/page.h /* Sparc64 is slow at multiplication, we prefer to use some extra space. */ #define WANT_PAGE_VIRTUAL 1 include/asm-ppc64/page.h /* * XXX A bug in the current ppc64 compiler prevents an optimisation * where a divide is replaced by a multiply by shifted inverse. For * the moment use page->virtaul */ #define WANT_PAGE_VIRTUAL 1 |
From: Kanoj S. <kan...@ya...> - 2002-04-12 00:58:10
|
--- Keith Owens <ka...@oc...> wrote: > On Thu, 11 Apr 2002 16:18:37 +0200, > Daniel Phillips <phi...@bo...> wrote: > >On April 12, 2002 12:38 am, Keith Owens wrote: > >> On Thu, 11 Apr 2002 12:08:33 +0200, > >> Daniel Phillips <phi...@bo...> wrote: > >> > > >> >Heads up: ->virtual may be eliminated in 2.5, > except for config_highmem. > >> > >> #define WANT_PAGE_VIRTUAL. AFAIK it is required > for sparc64 so I doubt > >> it will disappear. > >> > >> 2.5.8-pre3 include/linux/mm.h checks > >> #if defined(CONFIG_HIGHMEM) || > defined(WANT_PAGE_VIRTUAL) > > > >OK, fine. Out of interest, why is this something > sparc64 can't do without? > > include/asm-sparc64/page.h > /* Sparc64 is slow at multiplication, we prefer to > use some extra space. */ > #define WANT_PAGE_VIRTUAL 1 > > include/asm-ppc64/page.h > /* > * XXX A bug in the current ppc64 compiler prevents > an optimisation > * where a divide is replaced by a multiply by > shifted inverse. For > * the moment use page->virtaul > */ > #define WANT_PAGE_VIRTUAL 1 Well, that should definitely inspire people to keep the size of struct page constant, specifically to a power of 2, so that these guys can use shifts and give up page->virtual. Kanoj > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
From: Daniel P. <phi...@bo...> - 2002-04-12 01:06:38
|
On April 12, 2002 02:58 am, Kanoj Sarcar wrote: > --- Keith Owens <ka...@oc...> wrote: > > include/asm-ppc64/page.h > > /* > > * XXX A bug in the current ppc64 compiler prevents > > an optimisation > > * where a divide is replaced by a multiply by > > shifted inverse. For > > * the moment use page->virtaul > > */ > > #define WANT_PAGE_VIRTUAL 1 > > Well, that should definitely inspire people to keep > the size of struct page constant, specifically to > a power of 2, so that these guys can use shifts and > give up page->virtual. Right, and did anyone consider the possibility of fixing the bug? -- Daniel |
From: Anton B. <an...@sa...> - 2002-04-12 16:37:55
|
> Right, and did anyone consider the possibility of fixing the bug? Alan Modra has fixed this bug in recent versions of ppc64 gcc. I'll take it out once most people have upgraded their toolchain. Anton |
From: Daniel P. <phi...@bo...> - 2002-04-17 14:38:35
|
On Friday 12 April 2002 18:37, Anton Blanchard wrote: > > Right, and did anyone consider the possibility of fixing the bug? > > Alan Modra has fixed this bug in recent versions of ppc64 gcc. I'll > take it out once most people have upgraded their toolchain. Oops, sorry, I should have read all the way through the list before complaining about it again just above. -- Daniel |
From: Rik v. R. <ri...@co...> - 2002-04-12 01:07:01
|
On Thu, 11 Apr 2002, Kanoj Sarcar wrote: > Well, that should definitely inspire people to keep > the size of struct page constant, specifically to > a power of 2, so that these guys can use shifts and > give up page->virtual. "Lets keep struct page a power of 2 so we can drop a field" ... that makes surprisingly little sense to my tired mind ;) cheer, Rik -- Will hack the VM for food. http://www.surriel.com/ http://distro.conectiva.com/ |
From: Kanoj S. <kan...@ya...> - 2002-04-12 01:10:18
|
--- Rik van Riel <ri...@co...> wrote: > On Thu, 11 Apr 2002, Kanoj Sarcar wrote: > > > Well, that should definitely inspire people to > keep > > the size of struct page constant, specifically to > > a power of 2, so that these guys can use shifts > and > > give up page->virtual. > > "Lets keep struct page a power of 2 so we can drop a > field" > > ... that makes surprisingly little sense to my tired > mind ;) So that to go from a kernel address to its struct page and vice versa need not involve mult/div (with size of struct page), just left or right shifts (of log2 struct page size). Kanoj > > cheer, > > Rik > -- > Will hack the VM for food. > > http://www.surriel.com/ > http://distro.conectiva.com/ > > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
From: Thomas D. <td...@di...> - 2002-04-12 01:49:54
|
[cc list trimmed] On Thu, 2002-04-11 at 18:10, Kanoj Sarcar wrote: > > --- Rik van Riel <ri...@co...> wrote: > > "Lets keep struct page a power of 2 so we can drop a > > field" > > > > ... that makes surprisingly little sense to my tired > > mind ;) > > So that to go from a kernel address to its struct page > and vice versa need not involve mult/div (with size > of struct page), just left or right shifts (of log2 > struct page size). I think what Rik was trying to say is that the doesn't make much sense to eliminate the "virtual" field in the page struct if because that entry is no longer there, you have to maintain the struct as a power of 2 in order to make mults/divs cheap on some hw. -tduffy |
From: Daniel P. <phi...@bo...> - 2002-04-17 14:33:32
|
On Friday 12 April 2002 03:49, Thomas Duffy wrote: > [cc list trimmed] > > On Thu, 2002-04-11 at 18:10, Kanoj Sarcar wrote: > > > > --- Rik van Riel <ri...@co...> wrote: > > > "Lets keep struct page a power of 2 so we can drop a > > > field" > > > > > > ... that makes surprisingly little sense to my tired > > > mind ;) > > > > So that to go from a kernel address to its struct page > > and vice versa need not involve mult/div (with size > > of struct page), just left or right shifts (of log2 > > struct page size). > > I think what Rik was trying to say is that the doesn't make much sense > to eliminate the "virtual" field in the page struct if because that > entry is no longer there, you have to maintain the struct as a power of > 2 in order to make mults/divs cheap on some hw. It would be nice if it were possible to identify a per-page field or two that would be equally happy as a member of struct page or an element of a separate vector and wrap such a field in a get/set_somefield(page) inline so that the field can be optionally excluded from struct page to bring the size to a power-of-2 value. That said, I'll put this idea away. The multiply isn't that horrible for the ordinal_to_page conversion and either an optimized divide or a field implicitly recording the page number will do for page_to_ordinal. Whatever the spar64 compiler bug is that prevents the divide from being optimized, it should be fixed. There is no reasonable excuse for failing to do so. This doesn't affect the structure of the config_nonlinear patch or its applicability to sparc, since the page_to_ordinal conversion is per-architecture. I suppose it will stay that way, though I am considering the idea of giving the page.h's of all architectures a good scrubbing. Some of them are pretty filthy at the moment. At this point I favor the idea of creating a page_common.h to be included from the per-arch page.h, and which would contain some number of generic conversions that are applicable to most architectures. The sparc64 architecture, for example, could simply fail to include page_common.h and use a cut, pasted and hacked version instead. However, since we already have a config option for this (WANT_PAGE_VIRTUAL) we may be within sight of being able to write page_common.h in a completely cross-architecture way. -- Daniel |
From: Daniel P. <phi...@bo...> - 2002-04-12 00:19:58
|
On April 12, 2002 12:38 am, Keith Owens wrote: > On Thu, 11 Apr 2002 12:08:33 +0200, > Daniel Phillips <phi...@bo...> wrote: > > > >Heads up: ->virtual may be eliminated in 2.5, except for config_highmem. > > #define WANT_PAGE_VIRTUAL. AFAIK it is required for sparc64 so I doubt > it will disappear. > > 2.5.8-pre3 include/linux/mm.h checks > #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) OK, fine. Out of interest, why is this something sparc64 can't do without? -- Daniel |
From: Rik v. R. <ri...@co...> - 2002-04-12 00:39:29
|
On Thu, 11 Apr 2002, Daniel Phillips wrote: > On April 12, 2002 12:38 am, Keith Owens wrote: > > #define WANT_PAGE_VIRTUAL. AFAIK it is required for sparc64 so I doubt > > it will disappear. > > > > 2.5.8-pre3 include/linux/mm.h checks > > #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) > > OK, fine. Out of interest, why is this something sparc64 can't do without? It can, but it's slow at multiplication so sparc64 runs faster with page->virtual. regards, Rik -- Will hack the VM for food. http://www.surriel.com/ http://distro.conectiva.com/ |
From: Matthew W. <wi...@fc...> - 2002-04-12 12:48:41
|
On Thu, Apr 11, 2002 at 04:18:37PM +0200, Daniel Phillips wrote: > > 2.5.8-pre3 include/linux/mm.h checks > > #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) > > OK, fine. Out of interest, why is this something sparc64 can't do without? FYI, parisc64 is likely to retain the ->virtual field in order to turn flush_dcache_page into a no-op. But nobody's written that code yet :-) -- It's always legal to use Linux (TM) systems http://www.gnu.org/philosophy/why-free.html |
From: Daniel P. <phi...@bo...> - 2002-04-17 16:08:18
|
On Friday 12 April 2002 14:40, Matthew Wilcox wrote: > On Thu, Apr 11, 2002 at 04:18:37PM +0200, Daniel Phillips wrote: > > > 2.5.8-pre3 include/linux/mm.h checks > > > #if defined(CONFIG_HIGHMEM) || defined(WANT_PAGE_VIRTUAL) > > > > OK, fine. Out of interest, why is this something sparc64 can't do without? > > FYI, parisc64 is likely to retain the ->virtual field in order to turn > flush_dcache_page into a no-op. But nobody's written that code yet :-) Hi Matthew, The flush_dcache_page part is a little cryptic, could you please elaborate? -- Daniel |
From: Matthew W. <wi...@fc...> - 2002-04-17 17:01:19
|
On Tue, Apr 16, 2002 at 05:58:55PM +0200, Daniel Phillips wrote: > On Friday 12 April 2002 14:40, Matthew Wilcox wrote: > > FYI, parisc64 is likely to retain the ->virtual field in order to turn > > flush_dcache_page into a no-op. But nobody's written that code yet :-) > > Hi Matthew, > > The flush_dcache_page part is a little cryptic, could you please elaborate? Certainly. PA-RISC 2.0 has a 96-bit virtual address space. The top bits are determined by space registers, and the bottom bits by the general register you're using. While this is a virtually indexed cache, it is possible to get read-write coherency by using an /equivalent alias/. Aliases which are separated by a multiple of 4MB in this 96-bit virtual address space are guaranteed to be coherent. We already force user-space shared mmaps to be equivalent aliases, but rely on the kernel calling flush_dcache_page after it has written to a non-equivalent alias. Now, if the kernel only writes to an equivalent alias, the processor guarantees coherency and flush_dcache_page can be a no-op. So my proposed scheme is to use kmap/kunmap to return an address for a page which will be equivalent. The plan is to take up a 256TB chunk of the kernel's virtual address space to allow 256GB of memory to be mapped. We'll use the ->virtual member to indicate what address to return. -- It's always legal to use Linux (TM) systems http://www.gnu.org/philosophy/why-free.html |
From: Daniel P. <phi...@bo...> - 2002-04-19 16:09:11
|
On Wednesday 17 April 2002 18:53, Matthew Wilcox wrote: > On Tue, Apr 16, 2002 at 05:58:55PM +0200, Daniel Phillips wrote: > > The flush_dcache_page part is a little cryptic, could you please elaborate? > > Certainly. PA-RISC 2.0 has a 96-bit virtual address space. The top > bits are determined by space registers, and the bottom bits by the > general register you're using. Could you please explain why giving special interpretations to bits in the virtual address is not idiotic? It seems idiotic to me. -- Daniel |