headers
Rik van Riel | 1 Dec 2002 21:35
Picon
Favicon

[PATCH] 2.4.20-rmap15a

This is a merge of rmap15a with marcelo's 2.4 bitkeeper tree,
which is identical to 2.4.20-rc4 (he didn't push the makefile
update).  The only thing left out of the merge for now is
Andrew Morton's read_latency patch, both because I'm not sure
how needed it is with the elevator updates and because this
part of the merge was too tricky to do at merge time; I'll port
over Andrew Morton's read_latency patch later...

The first maintenance release of the 15th version of the reverse
mapping based VM is now available.
This is an attempt at making a more robust and flexible VM
subsystem, while cleaning up a lot of code at the same time.
The patch is available from:

           http://surriel.com/patches/2.4/2.4.20-rmap15a
and        http://linuxvm.bkbits.net/

My big TODO items for a next release are:
  - backport speedups from 2.5
  - pte-highmem

rmap 15a:
  - more agressive freeing for higher order allocations   (me)
  - export __find_pagecache_page, find_get_page define    (me, Cristoph, Arjan)
  - make memory statistics SMP safe again                 (me)
  - make page aging slow down again when needed           (Andrew Morton)
  - first stab at fine-tuning arjan's O(1) VM             (me)
  - split active list in cache / working set              (me)
  - fix SMP locking in arjan's O(1) VM                    (me)
rmap 15:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Hellwig | 3 Dec 2002 00:28
Picon
Favicon

[PATCH] undo __find_pagecache_page braindamage in -rmap15

Just revert back to the mainline versions of that stuff (which are the
same except of the naming).

Note that the changes are not only useless but also unintuitive, the
old name explained exactly what this function does, and the pagecache
is superflous as all find_*_page functions operate on the pagecache..

--- 1.15/Changelog.rmap	Tue Nov 26 14:26:20 2002
+++ edited/Changelog.rmap	Mon Dec  2 17:09:05 2002
 <at>  <at>  -12,9 +12,10  <at>  <at> 
   - backport speedups from 2.5
   - pte-highmem

+  - undo __find_pagecache_page braindamage		  (Christoph Hellwig)
 rmap 15a:
   - more agressive freeing for higher order allocations   (me)
-  - export __find_pagecache_page, find_get_page define    (me, Cristoph, Arjan)
+  - export __find_pagecache_page, find_get_page define    (me, Christoph, Arjan)
   - make memory statistics SMP safe again                 (me)
   - make page aging slow down again when needed           (Andrew Morton)
   - first stab at fine-tuning arjan's O(1) VM             (me)
===== include/linux/pagemap.h 1.20 vs edited =====
--- 1.20/include/linux/pagemap.h	Fri Nov 29 02:18:13 2002
+++ edited/include/linux/pagemap.h	Mon Dec  2 17:02:43 2002
 <at>  <at>  -70,6 +70,10  <at>  <at> 

 #define page_hash(mapping,index) (page_hash_table+_page_hashfn(mapping,index))

+extern struct page * __find_get_page(struct address_space *mapping,
+				unsigned long index, struct page **hash);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 3 Dec 2002 07:48

2.5.50-mm1

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

Nothing particularly exciting here.  There are two diffs at the above
site: 2.5.50-mm1.gz is the full patch, and 2.5.50-mm1-shpte.gz is
everything up to `shpte-always-on.patch'.  The latter is for Dave to
create diffs against.

Changes since 2.5.49-mm2:

+fbcon-timer-fix.patch
+hugepage-fixes.patch

 Random fixes

+ext3-oldalloc.patch

 Add the `oldalloc' and `orlov' mount options to ext3.

 ext3 has taken a big performance hit in dbench-on-scsi-on-SMP.  This
 is due to the Orlov allocator triggering a weakness in the ext2/ext3
 block allocator design.

 For a full analysis and protopatches see
 http://sourceforge.net/mailarchive/forum.php?thread_id=1365460&forum_id=6379

 Bottom line: we need to strengthen the block allocator.  The `oldalloc'
 mount option can be used to determine whether any performance regression
 is due to this problem.  Same deal with ext2, which is also affected.

+dio-return-partial-result.patch
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Neakums | 3 Dec 2002 17:39

Re: [PATCH] 2.4.20-rmap15a

commence  Rik van Riel quotation:

> This is a merge of rmap15a with marcelo's 2.4 bitkeeper tree,
> which is identical to 2.4.20-rc4 (he didn't push the makefile
> update).  The only thing left out of the merge for now is
> Andrew Morton's read_latency patch, both because I'm not sure
> how needed it is with the elevator updates and because this
> part of the merge was too tricky to do at merge time; I'll port
> over Andrew Morton's read_latency patch later...

I'm seeing a difference in wall-clock time of about nine minutes for
an lnx-bbc build (http://www.lnx-bbc.org/).  Dave Barry, another
lnx-bbc developer, has observed something similar.  The difference in
system times seems to be above noise, too.  Both of the kernels I used
also had Stephen Tweedie's ext3 updates for 2.4.20 applied[0].  I can
retest without, if you wish.  I believe Dave's kernels had only rmap
applied, however.

2.4.20:
real    106m26.147s
user    62m54.340s
sys     26m54.670s

2.4.20-rmap15a:
real    115m5.283s
user    63m50.580s
sys     29m34.520s

I used ccache with these builds and they are almost entirely cached
(the big exception being gcc), so the job becomes fairly I/O-bound as
(Continue reading)

Permalink | Reply | 7 comments |
headers
The One True Dave Barry | 3 Dec 2002 20:58

Re: [PATCH] 2.4.20-rmap15a

Quothe Sean Neakums <sneakums <at> zork.net>, on Tue, Dec 03, 2002:
> Dave Barry, another
> lnx-bbc developer, has observed something similar.  The difference in
> system times seems to be above noise, too.  Both of the kernels I used
> also had Stephen Tweedie's ext3 updates for 2.4.20 applied[0].  I can
> retest without, if you wish.  I believe Dave's kernels had only rmap
> applied, however.

	This is correct, and believe it or not i'm even using
	2.4.19 + rmap15a, no other patches.  I don't have my hard
	numbers available, but the difference between builds was quite
	significant, something like:

	2.4.19 vanilla:
	real 85m

	2.4.19-rmap15a:
	real 102m

> I used ccache with these builds and they are almost entirely cached
> (the big exception being gcc), so the job becomes fairly I/O-bound as
> a result.  The builds are quite big: the CVS tree unpacks and builds
> about three hundred megabytes of source, resulting in a build
> footprint of approximately 2.9GiB.  

	This applies to me as well.

>The volume I used for the build is
> formatted as ext3, with htree activated.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Martin J. Bligh | 3 Dec 2002 21:08

Re: [PATCH] 2.4.20-rmap15a

> 	This is correct, and believe it or not i'm even using
> 	2.4.19 + rmap15a, no other patches.  I don't have my hard
> 	numbers available, but the difference between builds was quite
> 	significant, something like:
>
> 	2.4.19 vanilla:
> 	real 85m
>
> 	2.4.19-rmap15a:
> 	real 102m

Assuming the extra time is eaten in Sys, not User, can you get a profile
of each, & post them?

M.

--
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 | 5 comments |
headers
Rik van Riel | 3 Dec 2002 21:56
Picon
Favicon

Re: [PATCH] 2.4.20-rmap15a

On Tue, 3 Dec 2002, Martin J. Bligh wrote:

> Assuming the extra time is eaten in Sys, not User,

It's not. It's idle time.  Looks like something very strange
is going on, vmstat and top output would be nice to have...

Rik
--

-- 
A: No.
Q: Should I include quotations after my reply?

http://www.surriel.com/		http://distro.conectiva.com/
--
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 | 4 comments |
headers
Sean Neakums | 4 Dec 2002 12:28

Re: [PATCH] 2.4.20-rmap15a

commence  Rik van Riel quotation:

> On Tue, 3 Dec 2002, Martin J. Bligh wrote:
>
>> Assuming the extra time is eaten in Sys, not User,
>
> It's not. It's idle time.  Looks like something very strange
> is going on, vmstat and top output would be nice to have...

Just did a build on 2.4.20-rmap15a.  The wall clock time is lower
than the previous build, but please don't draw any conclusions from
that until I have a 2.4.20 build redone.

real    108m38.567s
user    62m46.480s
sys     29m10.220s

I wasn't sure exactly how you wanted top and vmstat sampled, so I took
them every ten minutes.  ccache stats are in there also.  The first
sample was taken before the build was started, and the last after it
had completed.


Wed Dec  4 09:23:14 GMT 2002
top - 09:23:15 up 12 min,  5 users,  load average: 0.01, 0.12, 0.12
Tasks:  55 total,   1 running,  54 sleeping,   0 stopped,   0 zombie
Cpu(s):   6.1% user,   3.9% system,   0.0% nice,  90.0% idle
Mem:    254580k total,   200680k used,    53900k free,    95272k buffers
Swap:   265064k total,     1620k used,   263444k free,    50180k cached
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arjan van de Ven | 4 Dec 2002 12:40
Picon
Favicon

Re: [PATCH] 2.4.20-rmap15a

On Tue, 2002-12-03 at 21:56, Rik van Riel wrote:
> On Tue, 3 Dec 2002, Martin J. Bligh wrote:
> 
> > Assuming the extra time is eaten in Sys, not User,
> 
> It's not. It's idle time.  Looks like something very strange
> is going on, vmstat and top output would be nice to have...

I wonder if we miss a run of the tq_disk somewhere.....
--
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 | 1 comment |
headers
Rik van Riel | 4 Dec 2002 13:12
Picon
Favicon

Re: [PATCH] 2.4.20-rmap15a

On Wed, 4 Dec 2002, Arjan van de Ven wrote:
> On Tue, 2002-12-03 at 21:56, Rik van Riel wrote:
> > On Tue, 3 Dec 2002, Martin J. Bligh wrote:
> >
> > > Assuming the extra time is eaten in Sys, not User,
> >
> > It's not. It's idle time.  Looks like something very strange
> > is going on, vmstat and top output would be nice to have...
>
> I wonder if we miss a run of the tq_disk somewhere.....

The most likely cause, indeed.

Rik
--

-- 
A: No.
Q: Should I include quotations after my reply?

http://www.surriel.com/		http://distro.conectiva.com/
--
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