To large page or not to large page

It seems as tho Linux will map the kernel with large pages if the
processor allows it regardless if the lmb is sufficient to hold a
large page, correct?

Is there some runtime option to force the use of 4K pages.

Ultimately, my desire is to define a 256Mig segment that, using a
Hypervisor, that can be populated by shared pages that can physically
belong to the  hypervisor or other partions/domains) and restrict the
mappings to 4k.  I have some ideas, but am willing to hear any suggestions.

-JX

--

-- 
 "I got an idea, an idea so smart my head would explode if I even
  began to know what I was talking about." -- Peter Griffin (Family Guy)

Re: [PATCH 6/9] powerpc: merge idle_power4.S and fixup traps.c

On Fri, 30 Sep 2005 15:52:40 -0500 Kumar Gala <kumar.gala <at> freescale.com> wrote:
>
> (My first attempt at posting to the list failed due to size)

Yes, quoting the whole patch was probably not necessary 

> I really dont like the ideal of splitting up traps.c into traps32.c  
> and traps64.c.  This defeats the purpose of the merge.  I expect that  
> a significant portion of traps.c is common (or can be made to be)  
> between all powerpc's.

My first attempt at the merge was a real mess and a right pain, so I put
the two files in as a compromise.  However, I have made another attempt
and ,although it took a while,  it seems to be going ok.  How about we put
the two in for now (as that will allow the merge of more platforms to
continue) and I will supply a further patch in a few days that combines
the two trapsxx.c files?

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

_______________________________________________
Linuxppc64-dev mailing list
Linuxppc64-dev <at> ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc64-dev

Re: [PATCH 6/9] powerpc: merge idle_power4.S and fixup traps.c

Stephen Rothwell writes:

> My first attempt at the merge was a real mess and a right pain, so I put
> the two files in as a compromise.  However, I have made another attempt
> and ,although it took a while,  it seems to be going ok.  How about we put
> the two in for now (as that will allow the merge of more platforms to
> continue) and I will supply a further patch in a few days that combines
> the two trapsxx.c files?

In that case, what is the advantage of having two traps*.c files in
arch/powerpc/kernel instead of having them in arch/ppc*/kernel?

Paul.

[PATCH 6/9] powerpc: merge idle_power4.S and traps.c

On Sat, 1 Oct 2005 13:28:56 +1000 Paul Mackerras <paulus <at> samba.org> wrote:
>
> Stephen Rothwell writes:
> 
> > My first attempt at the merge was a real mess and a right pain, so I put
> > the two files in as a compromise.  However, I have made another attempt
> > and ,although it took a while,  it seems to be going ok.  How about we put
> > the two in for now (as that will allow the merge of more platforms to
> > continue) and I will supply a further patch in a few days that combines
> > the two trapsxx.c files?
> 
> In that case, what is the advantage of having two traps*.c files in
> arch/powerpc/kernel instead of having them in arch/ppc*/kernel?

OK, thanks for keeping me honest :-)  Here is new versions of patches 6
and 7 (all the rest are the same as before).

---------------

Use idle_power4.S from ppc64 as we are not going to support
32 bit power4 in the merged tree.

Merge ppc64 traps.c into powerpc traps.c:
	use ppc64 versions of exception routine names
		(as they don't have StudlyCaps)
	make all the versions if die() have the same
		prototype

Signed-off-by: Stephen Rothwell <sfr <at> canb.auug.org.au>
---

Re: [PATCH 7/9] ppc64: simplify the build a little

New version to because of changes in 6/9

Signed-off-by: Stephen Rothwell <sfr <at> canb.auug.org.au>

---

 arch/powerpc/Makefile        |    1 -
 arch/powerpc/kernel/Makefile |   11 +++++++++--
 arch/ppc64/Makefile          |    2 +-
 arch/ppc64/kernel/Makefile   |   11 ++---------
 4 files changed, 12 insertions(+), 13 deletions(-)

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

bd142b70a6bd5522f7d95f0cec06091b93bb0715
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
 <at>  <at>  -121,7 +121,6  <at>  <at>  head-$(CONFIG_FSL_BOOKE)	:= arch/powerpc

 ifeq ($(CONFIG_PPC32),y)
 head-$(CONFIG_6xx)		+= arch/powerpc/kernel/idle_6xx.o
-head-$(CONFIG_POWER4)		+= arch/powerpc/kernel/idle_power4.o
 head-$(CONFIG_PPC_FPU)		+= arch/powerpc/kernel/fpu.o
 endif

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile

Re: [PATCH 6/9] powerpc: merge idle_power4.S and traps.c

On Sat, 1 Oct 2005 21:37:53 +1000 Stephen Rothwell <sfr <at> canb.auug.org.au> wrote:
>
> OK, thanks for keeping me honest   Here is new versions of patches 6
> and 7 (all the rest are the same as before).

Just in case anyone is wondering, the new patchset has been built for (my
configs) pSeries, iSeries, g5, ARCH=ppc, ARCH=powerpc ppc32 pmac,
ARCH=powerpc iSeries and I have booted the ARCH=powerpc iSeries kernel.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

_______________________________________________
Linuxppc64-dev mailing list
Linuxppc64-dev <at> ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc64-dev

Re: To large page or not to large page

On Fri, 2005-09-30 at 20:43 -0400, Jimi Xenidis wrote:
> It seems as tho Linux will map the kernel with large pages if the
> processor allows it regardless if the lmb is sufficient to hold a
> large page, correct?
> 
> Is there some runtime option to force the use of 4K pages.
> 
> Ultimately, my desire is to define a 256Mig segment that, using a
> Hypervisor, that can be populated by shared pages that can physically
> belong to the  hypervisor or other partions/domains) and restrict the
> mappings to 4k.  I have some ideas, but am willing to hear any suggestions.

Does that segment has to be part of the linear mapping ? Can't it just
be mapped afterward using a kernel virtual mapping ? Also, don't forget
that the 64k pages patch won't support 4k pages at all for performances
reasons when CONFIG_PPC_64K_PAGES is enabled (at least on processors
that have HW support for 64k pages) .

Ben?

Re: To large page or not to large page

>>>>> "BH" == Benjamin Herrenschmidt <benh <at> kernel.crashing.org> writes:

 BH> On Fri, 2005-09-30 at 20:43 -0400, Jimi Xenidis wrote:
 >> It seems as tho Linux will map the kernel with large pages if the
 >> processor allows it regardless if the lmb is sufficient to hold a
 >> large page, correct?
 >> 
 >> Is there some runtime option to force the use of 4K pages.
 >> 
 >> Ultimately, my desire is to define a 256Mig segment that, using a
 >> Hypervisor, that can be populated by shared pages that can physically
 >> belong to the  hypervisor or other partions/domains) and restrict the
 >> mappings to 4k.  I have some ideas, but am willing to hear any suggestions.

 BH> Does that segment has to be part of the linear mapping ?

Not sure what _you_ mean by "linear mapping".
More specifically I would like for:
  #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
to work, and the segment  to be managed.
I think that is the linear map.

 BH> Can't it just be mapped afterward using a kernel virtual mapping
 BH> ?

Can it? given the use of __pa()?
Should I consider a new REGION_ID()?

 BH> Also, don't forget that the 64k pages patch won't support 4k
 BH> pages at all for performances reasons when CONFIG_PPC_64K_PAGES

PMac motherboard information missing from /proc/cpuinfo

With 2.6.14-rc3 I no longer get the motherboard information in
/proc/cpuinfo.  With 2.6.13 I got this:

machine         : PowerMac7,3
motherboard     : PowerMac7,3 MacRISC4 Power Macintosh 

Now I only get this:

machine         : PowerMac

The information in /proc/device-tree is still complete.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[PATCH] NO_IDLE_HZ implementation for PPC64

Hello,
	The patch below implements NO_IDLE_HZ support for pSeries/PPC64. It
basically lets idle CPUs to cut off their timer ticks until they can.

Some notes about the patch:

- Patch is against 2.6.14-rc1 and has undergone some basic test
  (with an additional patch - also in the mail) on a Power4 box. I intend to 
  test on a Power5 box also sometime soon.

- Only pseries_shared_idle and pseries_dedicated_idle routines
  have been converted over to use this support, since I felt 
  cutting off ticks doesnt make sense if the idle routine is
  poll-based.

- Boot CPU cannot skip ticks. This is because of the current design wherein
  only boot CPU updates wall-clock/jiffies.

  I didn't see any particular reason why it has been designed like that
  (maybe to reduce lock contention on xtime_lock?). If we have to allow
  boot CPU also to skip ticks (which IMO we should), then this design
  needs to change, i.e we should allow xtime/jiffies to be updated
  from any CPU (like S390 allows). If people agree that this is the 
  right direction, then I can give it a shot next.

- By default the feature is disabled at bootup and has to be enabled
  by writing 0 to /proc/sys/kernel/hz_timer. This can be modifed
  later after the patch has undergone sufficient test. Also we can
  introduce a boottime argument to control this behaviour.