headers
Andrew Morton | 2 Jan 2003 03:14

2.5.53-mm3

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.53/2.5.53-mm3/

. 2.5.53-mm2 was a bit sick in the timekeeping and slab department.  That
  should be fixed here.

. The idea of using the slab head arrays for object preallocation has been
  abandoned.  It involved too many slab changes, and slab just explodes in
  your face when touched.  So I've used a custom reservation pool in the
  radix-tree code instead.

. I've spent two days chasing the memory leak which Con has reported and
  have thus far not been able to reproduce it (managed to collaterally 
  discover a swapoff lockup and an htree leak though).  It's probably an
  ext3/VM interaction.  Please keep an eye out for this.

Changes since 2.5.53-mm2:

-aic-bounce.patch
-ga2.patch
-reduce-random-context-switch-rate.patch
-file-nr-doc-fix.patch
-remove-memshared.patch
-bin2bcd.patch
-semtimedop-update.patch
-drain_local_pages.patch
-kmalloc_percpu.patch
-dont-aligns-vmas.patch
-remove-swappable.patch
-remove-hugetlb-syscalls.patch
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Jan 2003 05:13

Re: 2.5.53-mm3

Andrew Morton wrote:
> 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.53/2.5.53-mm3/
> 

2.5.54-mm1 is at

  http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.54/2.5.54-mm1/

it is identical to 2.5.53-mm3.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |
headers
William Lee Irwin III | 2 Jan 2003 05:53

Re: 2.5.53-mm2

On Sat, Dec 28, 2002 at 04:52:20PM -0800, Andrew Morton wrote:
> wli-11_pgd_ctor.patch
>   (undescribed patch)

A moment's reflection on the subject suggests to me it's worthwhile to
generalize pgd_ctor support so it works (without #ifdefs!) on both PAE
and non-PAE. This tiny tweak is actually more noticeably beneficial
on non-PAE systems but only really because pgd_alloc() is more visible;
the most likely reason it's less visible on PAE is "other overhead".
It looks particularly nice since it removes more code than it adds.

Touch tested on NUMA-Q (PAE). OFTC #kn testers testing the non-PAE case.

 arch/i386/mm/init.c               |   36 +++++++++++++----------
 arch/i386/mm/pgtable.c            |   58 ++++++++++++--------------------------
 include/asm-i386/pgtable-3level.h |    2 -
 include/asm-i386/pgtable.h        |   13 +-------
 4 files changed, 41 insertions(+), 68 deletions(-)

diff -urpN mm3-2.5.53-1/arch/i386/mm/init.c mm3-2.5.53-2/arch/i386/mm/init.c
--- mm3-2.5.53-1/arch/i386/mm/init.c	2003-01-01 18:49:19.000000000 -0800
+++ mm3-2.5.53-2/arch/i386/mm/init.c	2003-01-01 18:51:17.000000000 -0800
 <at>  <at>  -504,32 +504,36  <at>  <at>  void __init mem_init(void)
 #endif
 }

-#if CONFIG_X86_PAE
 #include <linux/slab.h>

-kmem_cache_t *pae_pmd_cachep;
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Lee Irwin III | 2 Jan 2003 06:25

Re: 2.5.53-mm2

On Sat, Dec 28, 2002 at 04:52:20PM -0800, Andrew Morton wrote:
>> wli-11_pgd_ctor.patch

On Wed, Jan 01, 2003 at 08:53:27PM -0800, William Lee Irwin III wrote:
> A moment's reflection on the subject suggests to me it's worthwhile to
> generalize pgd_ctor support so it works (without #ifdefs!) on both PAE
> and non-PAE. This tiny tweak is actually more noticeably beneficial
> on non-PAE systems but only really because pgd_alloc() is more visible;
> the most likely reason it's less visible on PAE is "other overhead".
> It looks particularly nice since it removes more code than it adds.
> Touch tested on NUMA-Q (PAE). OFTC #kn testers testing the non-PAE case.

For those needing more interpretation, this is essentially a reinstatement
of the 2.4.x-style pgd/pmd cache optimization in a leak-free and accounted
(in /proc/slabinfo) manner.

The point of the optimizations is that these initializations are large
cache hits to take in a single shot, and in the PAE case, amount to a
full L1 cache flush as they traverse almost an entire 16K.

No rigorous benchmarking has been done yet.

Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Jan 2003 13:56

2.5.54-mm2

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.54/2.5.54-mm2/

A couple of crash fixes here.

Since 2.5.54-mm1:

+no-stem-compression.patch

 top(1) crashes for me.  Back out the stem compression code while
 it's being sorted out.

-quota-smp-locks.patch

 Merged

page_add_rmap-rework.patch

 Was causing an oops in X startup.   Fixed.

-teeny-mem-limits.patch
-smaller-head-arrays.patch
+#teeny-mem-limits.patch
+#smaller-head-arrays.patch

 Go back to the usual memory reserve levels.

+wli-11_pgd_ctor-update.patch

 Use pgds-from-slab and pmds-from-slab on non-PAE machines too.
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 4 Jan 2003 10:00

2.5.54-mm3

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.54/2.5.54-mm3/

Several patches here which fix pretty much the last source of long
scheduling latency stalls in the core kernel - long-held page_table_lock
during pagetable teardown.

The preemptible kernel now achieves around 500 microsecond worst-case
latency on a 500MHz PIII (with a slow memory system).  This is about as
good as the 2.4 low-latency patch.  Maybe better.

This is with ext2, and only with ext2.  Other filesystems need work
to reach that level of performance.

Non-preemptible kernels will benefit as well.  This sort of means that
preemptibility is only really needed for specialised multimedia/control
type apps.   Opinions vary ;)

Filesystem mount and unmount is a problem.  Probably, this will not be
addressed.  People who have specialised latency requirements should avoid
using automounters and those gadgets which poll CDROMs for insertion events.

This work has broken the shared pagetable patch - it touches the same code
in many places.   I shall put Humpty together again, but will not be 
including it for some time.  This is because there may be bugs in this
patch series which are accidentally fixed in the shared pagetable patch. So
shared pagetables will be reintegrated when these changes have had sufficient
testing.

Hugh, could you please closely review these changes sometime?   Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Barnhart | 4 Jan 2003 16:47
Picon

Re: 2.5.54-mm3

On Sat, 04 Jan 2003 01:00:38 +0000, Andrew Morton wrote:

> Filesystem mount and unmount is a problem.  Probably, this will not be
> addressed.  People who have specialised latency requirements should avoid
> using automounters and those gadgets which poll CDROMs for insertion events.

That stinks...it don't work in .54 and I'd likem to have my automounter
functioning again. Oh well it *is* 2.5.

> This work has broken the shared pagetable patch - it touches the same code
> in many places.   I shall put Humpty together again, but will not be 
> including it for some time.  This is because there may be bugs in this
> patch series which are accidentally fixed in the shared pagetable patch. So
> shared pagetables will be reintegrated when these changes have had sufficient
> testing.

Also for some reason I always have to do a "touch /fastboot" and boot in
rw mode to boot the kernel. The kernel fails on remouting fs in r-w mode.
X also don't work saying /dev/agpgart don't exist even though it does and
I saw it. agpgart module is loaded..maybe it would work as built into the
kernel? .config attached.

Steven
Permalink | Reply | 0 comments |
headers
Andrew Morton | 4 Jan 2003 22:18

Re: 2.5.54-mm3

Steven Barnhart wrote:
> 
> On Sat, 04 Jan 2003 01:00:38 +0000, Andrew Morton wrote:
> 
> > Filesystem mount and unmount is a problem.  Probably, this will not be
> > addressed.  People who have specialised latency requirements should avoid
> > using automounters and those gadgets which poll CDROMs for insertion events.
> 
> That stinks...it don't work in .54 and I'd likem to have my automounter
> functioning again. Oh well it *is* 2.5.

autofsv4 has been working fine across the 2.5 series.  You'll need to
send a (much) better report.

> > This work has broken the shared pagetable patch - it touches the same code
> > in many places.   I shall put Humpty together again, but will not be
> > including it for some time.  This is because there may be bugs in this
> > patch series which are accidentally fixed in the shared pagetable patch. So
> > shared pagetables will be reintegrated when these changes have had sufficient
> > testing.
> 
> Also for some reason I always have to do a "touch /fastboot" and boot in
> rw mode to boot the kernel. The kernel fails on remouting fs in r-w mode.

Many more details are needed.  Sufficient for a developer to be able to
reproduce the problem.

> X also don't work saying /dev/agpgart don't exist even though it does and
> I saw it. agpgart module is loaded..maybe it would work as built into the
> kernel? .config attached.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Papadopoulos | 5 Jan 2003 05:31

[PATCH] rewritten page coloring for 2.4.20 kernel

Hello. After a year in stasis, I've completely rebuilt my kernel
patch that implements page coloring. Improvements include:

- Page coloring is now hardwired into the kernel. The hash
  queues now use bootmem, and page coloring is always on. The
  patch still creates /proc/page_color for statistics, but that
  will go away in time.

- Automatic detection of external cache size on many architectures.
  I have no idea if any of this code works, since I don't have any
  of the target machines. The preferred way to initialize the coloring
  is by passing "page_color=<external cache size in kB>" as a boot 
  argument.

- NUMA-safe, discontig-safe

Right now the actual page coloring algorithm is the same as in previous
patches, and performs the same. In the next few weeks I'll be trying new
ideas that will hopefully reduce fragmentation and increase performance.
This is an early attempt to get some feedback on mistakes I may have made.

lmbench shows no real gains or losses compared to an unpatched kernel; 
some of the page fault and protection fault times are slightly slower, but
it's close to the rounding error over five lmbench runs. 

Here are all the performance results I have for the patch:

1. Compile of 2.4.20 kernel with gcc 3.1.1 on 466MHz DS10 Alphaserver with
   2MB cache: repeatable 1% speedup (573 sec vs. 579 sec)
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Lee Irwin III | 5 Jan 2003 06:07

Re: [PATCH] rewritten page coloring for 2.4.20 kernel

On Sat, Jan 04, 2003 at 11:31:11PM -0500, Jason Papadopoulos wrote:
> Hello. After a year in stasis, I've completely rebuilt my kernel
> patch that implements page coloring. Improvements include:
> - Page coloring is now hardwired into the kernel. The hash
>   queues now use bootmem, and page coloring is always on. The
>   patch still creates /proc/page_color for statistics, but that
>   will go away in time.
> - Automatic detection of external cache size on many architectures.
>   I have no idea if any of this code works, since I don't have any
>   of the target machines. The preferred way to initialize the coloring
>   is by passing "page_color=<external cache size in kB>" as a boot 
>   argument.
> - NUMA-safe, discontig-safe
> Right now the actual page coloring algorithm is the same as in previous
> patches, and performs the same. In the next few weeks I'll be trying new
> ideas that will hopefully reduce fragmentation and increase performance.
> This is an early attempt to get some feedback on mistakes I may have made.

Any chance for a 2.5.x-mm port? This is a bit feature-ish for 2.4.x.

Thanks,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |

Gmane