linux-toradex.git/arch/ppc64/mm, branch v2.6.13.4

[PATCH] ppc64: POWER 4 fails to boot with NUMA

2005-08-02T04:38:01+00:00

If CONFIG_NUMA is set, some POWER 4 systems will fail to boot.  This is
because of special processing needed to handle invalid node IDs (0xffff) on
POWER 4.  My previous patch to handle memory 'holes' within nodes forgot to
add this special case for POWER 4 in one place.

In reality, I'm not sure that configuring the kernel for NUMA on POWER 4 makes
much sense.  Are there POWER 4 based systems with NUMA characteristics that
are presented by the firmware?  But, distros want one kernel for all systems
so NUMA is on by default in their kernels.  The patch handles those cases.

Signed-off-by: Mike Kravetz 
Signed-off-by: Paul Mackerras 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: dynamically allocate segment tables

2005-07-27T23:25:58+00:00

PPC64 machines before Power4 need a segment table page allocated for each
CPU.  Currently these are allocated statically in a big array in head.S for
all CPUs.  The segment tables need to be in the first segment (so
do_stab_bolted doesn't take a recursive fault on the stab itself), but
other than that there are no constraints which require the stabs for the
secondary CPUs to be statically allocated.

This patch allocates segment tables dynamically during boot, using
lmb_alloc() to ensure they are within the first 256M segment.  This reduces
the kernel image size by 192k...

Tested on RS64 iSeries, POWER3 pSeries, and POWER5.

Signed-off-by: David Gibson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: kill bitfields in ppc64 hash code

2005-07-13T18:25:25+00:00

This patch removes the use of bitfield types from the ppc64 hash table
manipulation code.

Signed-off-by: David Gibson 
Acked-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64 kexec: native hash clear

2005-06-25T23:24:51+00:00

Add code to clear the hash table and invalidate the tlb for native (SMP,
non-LPAR) mode.  Supports 16M and 4k pages.

Signed-off-by: Milton Miller 
Signed-off-by: R Sharada 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: sparsemem memory model

2005-06-23T16:45:06+00:00

Provide the architecture specific implementation for SPARSEMEM for PPC64
systems.

Signed-off-by: Andy Whitcroft 
Signed-off-by: Dave Hansen 
Signed-off-by: Mike Kravetz  (in part)
Signed-off-by: Martin Bligh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: add memory present

2005-06-23T16:45:05+00:00

Provide hooks for PPC64 to allow memory models to be informed of installed
memory areas.  This allows SPARSEMEM to instantiate mem_map for the populated
areas.

Signed-off-by: Andy Whitcroft 
Signed-off-by: Dave Hansen 
Signed-off-by: Martin Bligh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] remove non-DISCONTIG use of pgdat->node_mem_map

2005-06-23T16:45:00+00:00

This patch effectively eliminates direct use of pgdat->node_mem_map outside
of the DISCONTIG code.  On a flat memory system, these fields aren't
currently used, neither are they on a sparsemem system.

There was also a node_mem_map(nid) macro on many architectures.  Its use
along with the use of ->node_mem_map itself was not consistent.  It has
been removed in favor of two new, more explicit, arch-independent macros:

	pgdat_page_nr(pgdat, pagenr)
	nid_page_nr(nid, pagenr)

I called them "pgdat" and "nid" because we overload the term "node" to mean
"NUMA node", "DISCONTIG node" or "pg_data_t" in very confusing ways.  I
believe the newer names are much clearer.

These macros can be overridden in the sparsemem case with a theoretically
slower operation using node_start_pfn and pfn_to_page(), instead.  We could
make this the only behavior if people want, but I don't want to change too
much at once.  One thing at a time.

This patch removes more code than it adds.

Compile tested on alpha, alpha discontig, arm, arm-discontig, i386, i386
generic, NUMAQ, Summit, ppc64, ppc64 discontig, and x86_64.  Full list
here: http://sr71.net/patches/2.6.12/2.6.12-rc1-mhp2/configs/

Boot tested on NUMAQ, x86 SMP and ppc64 power4/5 LPARs.

Signed-off-by: Dave Hansen 
Signed-off-by: Martin J. Bligh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: Mark kernel hptes dirty

2005-06-22T01:46:31+00:00

We dont use the hardware referenced and changed bits and setting them early
avoids a store to memory.  We already do this for userspace hptes but not
kernel ones.  Do it.

Signed-off-by: Anton Blanchard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: Abolish ioremap_mm

2005-06-22T01:46:26+00:00

Currently ppc64 has two mm_structs for the kernel, init_mm and also
ioremap_mm.  The latter really isn't necessary: this patch abolishes it,
instead restricting vmallocs to the lower 1TB of the init_mm's range and
placing io mappings in the upper 1TB.  This simplifies the code in a number
of places and eliminates an unecessary set of pagetables.  It also tweaks
the unmap/free path a little, allowing us to remove the unmap_im_area() set
of page table walkers, replacing them with unmap_vm_area().

Signed-off-by: David Gibson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Avoiding mmap fragmentation

2005-06-22T01:46:16+00:00

Ingo recently introduced a great speedup for allocating new mmaps using the
free_area_cache pointer which boosts the specweb SSL benchmark by 4-5% and
causes huge performance increases in thread creation.

The downside of this patch is that it does lead to fragmentation in the
mmap-ed areas (visible via /proc/self/maps), such that some applications
that work fine under 2.4 kernels quickly run out of memory on any 2.6
kernel.

The problem is twofold:

  1) the free_area_cache is used to continue a search for memory where
     the last search ended.  Before the change new areas were always
     searched from the base address on.

     So now new small areas are cluttering holes of all sizes
     throughout the whole mmap-able region whereas before small holes
     tended to close holes near the base leaving holes far from the base
     large and available for larger requests.

  2) the free_area_cache also is set to the location of the last
     munmap-ed area so in scenarios where we allocate e.g.  five regions of
     1K each, then free regions 4 2 3 in this order the next request for 1K
     will be placed in the position of the old region 3, whereas before we
     appended it to the still active region 1, placing it at the location
     of the old region 2.  Before we had 1 free region of 2K, now we only
     get two free regions of 1K -> fragmentation.

The patch addresses thes issues by introducing yet another cache descriptor
cached_hole_size that contains the largest known hole size below the
current free_area_cache.  If a new request comes in the size is compared
against the cached_hole_size and if the request can be filled with a hole
below free_area_cache the search is started from the base instead.

The results look promising: Whereas 2.6.12-rc4 fragments quickly and my
(earlier posted) leakme.c test program terminates after 50000+ iterations
with 96 distinct and fragmented maps in /proc/self/maps it performs nicely
(as expected) with thread creation, Ingo's test_str02 with 20000 threads
requires 0.7s system time.

Taking out Ingo's patch (un-patch available per request) by basically
deleting all mentions of free_area_cache from the kernel and starting the
search for new memory always at the respective bases we observe: leakme
terminates successfully with 11 distinctive hardly fragmented areas in
/proc/self/maps but thread creating is gringdingly slow: 30+s(!) system
time for Ingo's test_str02 with 20000 threads.

Now - drumroll ;-) the appended patch works fine with leakme: it ends with
only 7 distinct areas in /proc/self/maps and also thread creation seems
sufficiently fast with 0.71s for 20000 threads.

Signed-off-by: Wolfgang Wander 
Credit-to: "Richard Purdie" 
Signed-off-by: Ken Chen 
Acked-by: Ingo Molnar  (partly)
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds