why does the macro "ZERO_PAGE" take an argument?

why does the macro "ZERO_PAGE" take an argument?

[Robert P. J. Day]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[Nick Piggin]

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.

Re: why does the macro "ZERO_PAGE" take an argument?

[Robert P. J. Day]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[Satyam Sharma]

On 6/7/07, Robert P. J. Day <rpjday@mindspring.com> 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 ...

Re: why does the macro "ZERO_PAGE" take an argument?

[Robert P. J. Day]

On Thu, 7 Jun 2007, Satyam Sharma wrote:

> On 6/7/07, Robert P. J. Day <rpjday@mindspring.com> 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
========================================================================

Re: why does the macro "ZERO_PAGE" take an argument?

[Ralf Baechle]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[H. Peter Anvin]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[H. Peter Anvin]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[William Lee Irwin III]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[H. Peter Anvin]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[Robert P. J. Day]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[H. Peter Anvin]

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

Re: why does the macro "ZERO_PAGE" take an argument?

[Nick Piggin]

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.