probably making a fool of myself here, but what is the purpose of
that single argument to the macro "ZERO_PAGE"?
$ grep -r "define ZERO_PAGE" include
include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL; })
include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) virt_to_page(empty_zero_page)
include/asm-v850/pgtable.h:#define ZERO_PAGE(vaddr) ((void *)0x87654321)
include/asm-mips/pgtable.h:#define ZERO_PAGE(vaddr) \
include/asm-blackfin/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(0))
include/asm-parisc/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
include/asm-alpha/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(ZERO_PGE))
...
AFAICT, there are no definitions of that macro that actually use
that argument. is that some kind of historical cruft?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> probably making a fool of myself here, but what is the purpose of
> that single argument to the macro "ZERO_PAGE"?
>
> $ grep -r "define ZERO_PAGE" include
> include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL; })
> include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) virt_to_page(empty_zero_page)
> include/asm-v850/pgtable.h:#define ZERO_PAGE(vaddr) ((void *)0x87654321)
> include/asm-mips/pgtable.h:#define ZERO_PAGE(vaddr) \
> include/asm-blackfin/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(0))
> include/asm-parisc/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
> include/asm-alpha/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(ZERO_PGE))
> ...
>
> AFAICT, there are no definitions of that macro that actually use
> that argument. is that some kind of historical cruft?
MIPS?
--
SUSE Labs, Novell Inc.
On Thu, 7 Jun 2007, Nick Piggin wrote:
> Robert P. J. Day wrote:
> > probably making a fool of myself here, but what is the purpose of
> > that single argument to the macro "ZERO_PAGE"?
> >
> > $ grep -r "define ZERO_PAGE" include
> > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL; })
> > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr)
> > virt_to_page(empty_zero_page)
> > include/asm-v850/pgtable.h:#define ZERO_PAGE(vaddr) ((void *)0x87654321)
> > include/asm-mips/pgtable.h:#define ZERO_PAGE(vaddr) \
> > include/asm-blackfin/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(0))
> > include/asm-parisc/pgtable.h:#define ZERO_PAGE(vaddr)
> > (virt_to_page(empty_zero_page))
> > include/asm-alpha/pgtable.h:#define ZERO_PAGE(vaddr)
> > (virt_to_page(ZERO_PGE))
> > ...
> >
> > AFAICT, there are no definitions of that macro that actually use
> > that argument. is that some kind of historical cruft?
>
> MIPS?
argh. that would be the *one* definition whose output got chopped
because of line continuation, and it would be only one that actually
uses the argument:
#define ZERO_PAGE(vaddr) \
(virt_to_page((void *)(empty_zero_page + (((unsigned long)(vaddr)) & zero_page_mask))))
but it still leaves the question -- if ZERO_PAGE is meant to represent
a single, global shared page that is always zero, why would it *ever*
need to take an argument? and what's so special about MIPS that it
differs from all the rest?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On 6/7/07, Robert P. J. Day <[email protected]> wrote:
> On Thu, 7 Jun 2007, Nick Piggin wrote:
>
> > Robert P. J. Day wrote:
> > > probably making a fool of myself here, but what is the purpose of
> > > that single argument to the macro "ZERO_PAGE"?
> > >
> > > $ grep -r "define ZERO_PAGE" include
> > > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL; })
> > > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr)
> > > virt_to_page(empty_zero_page)
> > > include/asm-v850/pgtable.h:#define ZERO_PAGE(vaddr) ((void *)0x87654321)
> > > include/asm-mips/pgtable.h:#define ZERO_PAGE(vaddr) \
> > > include/asm-blackfin/pgtable.h:#define ZERO_PAGE(vaddr) (virt_to_page(0))
> > > include/asm-parisc/pgtable.h:#define ZERO_PAGE(vaddr)
> > > (virt_to_page(empty_zero_page))
> > > include/asm-alpha/pgtable.h:#define ZERO_PAGE(vaddr)
> > > (virt_to_page(ZERO_PGE))
> > > ...
> > >
> > > AFAICT, there are no definitions of that macro that actually use
> > > that argument. is that some kind of historical cruft?
> >
> > MIPS?
>
> argh. that would be the *one* definition whose output got chopped
> because of line continuation, and it would be only one that actually
> uses the argument:
>
> #define ZERO_PAGE(vaddr) \
> (virt_to_page((void *)(empty_zero_page + (((unsigned long)(vaddr)) & zero_page_mask))))
>
>
> but it still leaves the question -- if ZERO_PAGE is meant to represent
> a single, global shared page that is always zero, why would it *ever*
> need to take an argument? and what's so special about MIPS that it
> differs from all the rest?
The comment above empty_zero_page and zero_page_mask
declarations at arch/mips/mm/init.c:508 sheds light on this ...
On Thu, 7 Jun 2007, Satyam Sharma wrote:
> On 6/7/07, Robert P. J. Day <[email protected]> wrote:
> > On Thu, 7 Jun 2007, Nick Piggin wrote:
> >
> > > Robert P. J. Day wrote:
> > > > probably making a fool of myself here, but what is the purpose of
> > > > that single argument to the macro "ZERO_PAGE"?
> > > >
> > > > $ grep -r "define ZERO_PAGE" include
> > > > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL;
> > })
> > > > include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr)
> > > > virt_to_page(empty_zero_page)
> > > > include/asm-v850/pgtable.h:#define ZERO_PAGE(vaddr) ((void
> > *)0x87654321)
> > > > include/asm-mips/pgtable.h:#define ZERO_PAGE(vaddr) \
> > > > include/asm-blackfin/pgtable.h:#define ZERO_PAGE(vaddr)
> > (virt_to_page(0))
> > > > include/asm-parisc/pgtable.h:#define ZERO_PAGE(vaddr)
> > > > (virt_to_page(empty_zero_page))
> > > > include/asm-alpha/pgtable.h:#define ZERO_PAGE(vaddr)
> > > > (virt_to_page(ZERO_PGE))
> > > > ...
> > > >
> > > > AFAICT, there are no definitions of that macro that actually use
> > > > that argument. is that some kind of historical cruft?
> > >
> > > MIPS?
> >
> > argh. that would be the *one* definition whose output got chopped
> > because of line continuation, and it would be only one that actually
> > uses the argument:
> >
> > #define ZERO_PAGE(vaddr) \
> > (virt_to_page((void *)(empty_zero_page + (((unsigned long)(vaddr)) &
> > zero_page_mask))))
> >
> >
> > but it still leaves the question -- if ZERO_PAGE is meant to represent
> > a single, global shared page that is always zero, why would it *ever*
> > need to take an argument? and what's so special about MIPS that it
> > differs from all the rest?
>
> The comment above empty_zero_page and zero_page_mask
> declarations at arch/mips/mm/init.c:508 sheds light on this ...
well, it *sort of* does. at line 64 of that file:
/*
* We have up to 8 empty zeroed pages so we can map one of the right colour
* when needed. This is necessary only on R4000 / R4400 SC and MC versions
* where we have to avoid VCED / VECI exceptions for good performance at
* any price. Since page is never written to after the initialization we
* don't have to care about aliases on other CPUs.
*/
although it's not clear where in the source tree are the invocations
that would actually make a difference to a MIPS system, which is why
i've CC'ed ralf on this. i'm sure he can clear this up. :-)
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
>> The comment above empty_zero_page and zero_page_mask
>> declarations at arch/mips/mm/init.c:508 sheds light on this ...
>
> well, it *sort of* does. at line 64 of that file:
>
> /*
> * We have up to 8 empty zeroed pages so we can map one of the right colour
> * when needed. This is necessary only on R4000 / R4400 SC and MC versions
> * where we have to avoid VCED / VECI exceptions for good performance at
> * any price. Since page is never written to after the initialization we
> * don't have to care about aliases on other CPUs.
> */
>
> although it's not clear where in the source tree are the invocations
> that would actually make a difference to a MIPS system, which is why
> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
x86 could also benefit from coloured zeropages. In fact, I thought it
already had them (K8 wants as many as 8.)
-hpa
On Thu, Jun 07, 2007 at 07:53:08AM -0400, Robert P. J. Day wrote:
> > > > MIPS?
> > >
> > > argh. that would be the *one* definition whose output got chopped
> > > because of line continuation, and it would be only one that actually
> > > uses the argument:
> > >
> > > #define ZERO_PAGE(vaddr) \
> > > (virt_to_page((void *)(empty_zero_page + (((unsigned long)(vaddr)) &
> > > zero_page_mask))))
> > >
> > >
> > > but it still leaves the question -- if ZERO_PAGE is meant to represent
> > > a single, global shared page that is always zero, why would it *ever*
> > > need to take an argument? and what's so special about MIPS that it
> > > differs from all the rest?
> >
> > The comment above empty_zero_page and zero_page_mask
> > declarations at arch/mips/mm/init.c:508 sheds light on this ...
>
> well, it *sort of* does. at line 64 of that file:
>
> /*
> * We have up to 8 empty zeroed pages so we can map one of the right colour
> * when needed. This is necessary only on R4000 / R4400 SC and MC versions
> * where we have to avoid VCED / VECI exceptions for good performance at
> * any price. Since page is never written to after the initialization we
> * don't have to care about aliases on other CPUs.
> */
>
> although it's not clear where in the source tree are the invocations
> that would actually make a difference to a MIPS system, which is why
> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
Cache aliases. When the same page of physical memory is mapped twice to
user space, let's say at address addr and addr + PAGE_SIZE this is normally
harmless although wasteful on processors with virtually indexed caches as
long as the page is mapped read-only such as in case of ZERO_PAGE.
If the same thing happens with a writable page there is the chance of
severe data corruption. Some members of the R4000 family are now trying
to be helpful by throwing the kernel a "virtual coherency" exception. The
bad news about this exception is there might be thousands (the theoretical
worst case would be millions) of it in a single second, so servicing can be
very expensive. For the ZERO page this can be avoided by using several
pages mapped in a way such that their addresses don't conflict.
Ralf
Ralf Baechle wrote:
> Cache aliases. When the same page of physical memory is mapped twice to
> user space, let's say at address addr and addr + PAGE_SIZE this is normally
> harmless although wasteful on processors with virtually indexed caches as
> long as the page is mapped read-only such as in case of ZERO_PAGE.
>
> If the same thing happens with a writable page there is the chance of
> severe data corruption. Some members of the R4000 family are now trying
> to be helpful by throwing the kernel a "virtual coherency" exception. The
> bad news about this exception is there might be thousands (the theoretical
> worst case would be millions) of it in a single second, so servicing can be
> very expensive. For the ZERO page this can be avoided by using several
> pages mapped in a way such that their addresses don't conflict.
Note that it can be a *very expensive* waste even on machines that do
this in hardware. Colouring the zeropage can have sizable performance
advantages for virtually no cost.
-hpa
Robert P. J. Day wrote:
>> although it's not clear where in the source tree are the invocations
>> that would actually make a difference to a MIPS system, which is why
>> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
> x86 could also benefit from coloured zeropages. In fact, I thought it
> already had them (K8 wants as many as 8.)
How would one demonstrate the beneficial effect of such?
-- wli
William Lee Irwin III wrote:
> Robert P. J. Day wrote:
>>> although it's not clear where in the source tree are the invocations
>>> that would actually make a difference to a MIPS system, which is why
>>> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
>
> On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
>> x86 could also benefit from coloured zeropages. In fact, I thought it
>> already had them (K8 wants as many as 8.)
>
> How would one demonstrate the beneficial effect of such?
Dean Gaudet at Transmeta did some benchmarking using SPEC. If I recall
his numbers correctly (this is from memory, mind you) on Transmeta
Efficeon, which has 2-way virtual cache tagging with hardware recovery,
zeropage coloring was a 1.5% performance improvement.
-hpa
On Thu, 7 Jun 2007, H. Peter Anvin wrote:
> William Lee Irwin III wrote:
> > Robert P. J. Day wrote:
> >>> although it's not clear where in the source tree are the invocations
> >>> that would actually make a difference to a MIPS system, which is why
> >>> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
> >
> > On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
> >> x86 could also benefit from coloured zeropages. In fact, I thought it
> >> already had them (K8 wants as many as 8.)
> >
> > How would one demonstrate the beneficial effect of such?
>
> Dean Gaudet at Transmeta did some benchmarking using SPEC. If I
> recall his numbers correctly (this is from memory, mind you) on
> Transmeta Efficeon, which has 2-way virtual cache tagging with
> hardware recovery, zeropage coloring was a 1.5% performance
> improvement.
and once again, an initially innocuous question quickly leaves me
behind. no, no, i'm getting used to it. :-P
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
>
> and once again, an initially innocuous question quickly leaves me
> behind. no, no, i'm getting used to it. :-P
>
This is what happens when you stir the muck on the bottom. This is
probably a good thing.
-hpa
H. Peter Anvin wrote:
> William Lee Irwin III wrote:
>
>>Robert P. J. Day wrote:
>>
>>>>although it's not clear where in the source tree are the invocations
>>>>that would actually make a difference to a MIPS system, which is why
>>>>i've CC'ed ralf on this. i'm sure he can clear this up. :-)
>>
>>On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
>>
>>>x86 could also benefit from coloured zeropages. In fact, I thought it
>>>already had them (K8 wants as many as 8.)
>>
>>How would one demonstrate the beneficial effect of such?
>
>
> Dean Gaudet at Transmeta did some benchmarking using SPEC. If I recall
> his numbers correctly (this is from memory, mind you) on Transmeta
> Efficeon, which has 2-way virtual cache tagging with hardware recovery,
> zeropage coloring was a 1.5% performance improvement.
I'm surprised that the benchmark made such use of zero pages so as to
be worthwhile. I'm sitting on a patch which removes the zero page from
the page fault fastpath completely which I'd like to try out in -mm...
--
SUSE Labs, Novell Inc.