2.5.40-mm1

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

Mainly a resync.

- A few minor problems in the per-cpu-pages code have been fixed.

- Updated dcache RCU code.

- Significant brain surgery on the SARD patch.

- Decreased the disk scheduling tunable `fifo_batch' from 32 to 16 to
  improve disk read latency.

- Updated ext3 htree patch from Ted.

- Included a patch from Mala Anand which _should_ speed up kernel<->userspace
  memory copies for Intel ia32 hardware.  But I can't measure any difference
  with poorly-aligned pagecache copies.

-scsi_hack.patch
-might_sleep-2.patch
-slab-fix.patch
-hugetlb-doc.patch
-get_user_pages-PG_reserved.patch
-move_one_page_fix.patch
-zab-list_heads.patch
-remove-gfp_nfs.patch
-buddyinfo.patch
-free_area.patch
-per-node-kswapd.patch

Faster TCP wakeups

Hail Andrew,

I don't think we've met, but my name is Kingsley
G. Morse Jr. and first of all, I'd like to thank
you for improving the Linux kernel. I'm
benchmarking it.

I noticed in Kernel Traffic #186 that you've
converted TCP/IPV4 over to use faster wakeups.

This intrigues me, because I suspect TCP code is
degrading my computer's performance over time, and
perhaps other peoples' too.

My benchmarking found that after being up for 10
days, my computer's slowness is MOST correlated to
how often slab pages are allocated for TCP open
requests. (see "cat /proc/slabinfo")

In other words, the more often slab pages are
allocated for tcp open requests, the slower my
computer gets. 

The correlation coefficient is 0.62, which is on a
scale of -1 to 1. 

I believe it's noteworthy that 0.62 is higher than
any of the hundreds of other memory measures that
I've statistically analyzed.

hugetlbfs-2.5.40-1

hugetlbfs is a trivial filesystem exporting memory-backed files into
the fs namespace and providing the ability to mmap() such files using
hugetlb routines.

Outstanding issues:
------------------
(1) shm is still broken.
	(1A) shmctl still manages to find the wrong thing to do.
	(1B) shm permission checks are probably incorrect
(2) trivial dentry support needs to move to libfs.c
(3) compilation for when its option is turned off is still broken.
(4) hugetlb_prefault() duplicates some code it could be sharing.

New stuff:
---------
(1) hugetlbfs_file_mmap() now returns -EINVAL instead of passing
	unaligned args that would cause hugetlb_prefault() to BUG().
(2) shmdt() now has a chance of working since it now checks to see if
	it's detaching from a hugetlb segment.

Compiled, but not booted or run. I'm partially cut off from my testing
setup at the moment (and was under the weather for a day or so), but
need to push things out for others to test.

shmdt() may end up slightly more efficient if I didn't completely botch
it. The open-coded linear search ended up looking like a mess from all
the indentation and so on going on, so it seemed to be better this way.
If it causes trouble for the normal case, I'll back it out and do the
dispatch on ->vm_ops inside the loop or otherwise fix it.

my VM TODO list

-------

(1) hugetlbfs
	written, needs to return -EINVAL higher up instead of BUG_ON()
	lower down, and make shm bits DTRT.

(2) pagetable reclaim
	Figured out where the pmd weirdness happens and restarted
	lookups, need to find a spot to go blow them away, when
	to do it, and maybe do something about private anonymous.

(3) help out with pagetable sharing
	Not sure what's going on there.

-----
long-since vetoed/hated/whatever wishlist items omitted

Wishlist:
--------
(1) x86 page clustering
	Pretending 1 << order pte's are a single pte is easy.
	IA64 appears to have subpage mmapping code to cherry pick
	for 4KB compatibility, possibly omit it if it's a problem.

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/

Re: my VM TODO list

On Wed, 2 Oct 2002, William Lee Irwin III wrote:

> (2) pagetable reclaim
> 	Figured out where the pmd weirdness happens and restarted
> 	lookups, need to find a spot to go blow them away, when
> 	to do it, and maybe do something about private anonymous.
>
> (3) help out with pagetable sharing
> 	Not sure what's going on there.

I'm willing to help out with both of these.   Is there any current
code around I could take a look at and work from ?

Rik
--

-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september <at> surriel.com trac <at> trac.org

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

[PATCH] Snapshot of shared page tables

Ok, here it is.  This patch works for my simple tests, both under UP and
SMP, including under memory pressure.  I'd appreciate anyone who'd like to
take it and beat on it.  Please let me know of any problems you find.

The patch is against this morning's 2.5 BK tree.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr <at> us.ibm.com                                        T/L   678-3059

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.674   -> 1.675  
#	  include/linux/mm.h	1.83.1.2 -> 1.86   
#	include/asm-i386/pgalloc.h	1.16.1.2 -> 1.19   
#	       kernel/fork.c	1.70.1.15 -> 1.76   
#	            Makefile	1.293.1.22 -> 1.302  
#	include/linux/rmap-locking.h	1.1     -> 1.2    
#	         init/main.c	1.64.1.6 -> 1.69   
#	       mm/swapfile.c	1.54.1.2 -> 1.58   
#	           fs/exec.c	1.45.1.4 -> 1.49   
#	         mm/memory.c	1.84.1.6 -> 1.92   
#	include/asm-generic/rmap.h	1.2.1.1 -> 1.6    
#	include/linux/page-flags.h	1.24.1.1 -> 1.27   

Re: [PATCH] Snapshot of shared page tables

On Wednesday 02 October 2002 16:57, Dave McCracken wrote:
> 
> Ok, here it is.  This patch works for my simple tests, both under UP and
> SMP, including under memory pressure.  I'd appreciate anyone who'd like to
> take it and beat on it.  Please let me know of any problems you find.
> 
> The patch is against this morning's 2.5 BK tree.

Interesting, you substituted pte_page_lock(ptepage) for mm->page_table_lock.
Could you wax poetic about that, please?

--

-- 
Daniel
--
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/

Re: [PATCH] Snapshot of shared page tables

--On Wednesday, October 02, 2002 18:51:41 +0200 Daniel Phillips
<phillips <at> arcor.de> wrote:

> Interesting, you substituted pte_page_lock(ptepage) for
> mm->page_table_lock. Could you wax poetic about that, please?

Sure.  If a pte page is shared, the mm->page_table_lock is not sufficient
to protect the rest of the page fault.  Therefore we need a lock at the pte
page level.  The mm->page_table_lock is held during the page fault until we
have a valid and locked pte page we're working on, then it's dropped for
the rest of the fault.

Feel free to poke holes in my logic, but I think it's the right locking
model for shared pte pages.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr <at> us.ibm.com                                        T/L   678-3059

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

Re: [PATCH] Snapshot of shared page tables

On Wednesday 02 October 2002 18:51, Daniel Phillips wrote:
> On Wednesday 02 October 2002 16:57, Dave McCracken wrote:
> > 
> > Ok, here it is.  This patch works for my simple tests, both under UP and
> > SMP, including under memory pressure.  I'd appreciate anyone who'd like to
> > take it and beat on it.  Please let me know of any problems you find.
> > 
> > The patch is against this morning's 2.5 BK tree.
> 
> Interesting, you substituted pte_page_lock(ptepage) for mm->page_table_lock.
> Could you wax poetic about that, please?

Never mind, I see the logic.  This reflects the fact that page_table_lock
is insufficient protection when pte pages are shared.  So you solved that
problem and at the same time improved the scalability for the general case
immensely, without adding any new overhead.  Very nice!

--

-- 
Daniel
--
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/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35 + mm1, and 2.5.38 + mm3

Andrew Morton wrote:
> 
> Bill Hartner wrote:
> >
> > ...
> > 2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> > 2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> >
> 
> 2.5.35 was fairly wretched from the swapout point of view.
> Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
> 

Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
what ever is the latest and greatest on Friday.

SUT same as :

http://marc.theaimsgroup.com/?l=linux-mm&m=103229747000714&w=2

NOTE : the swap device is on ServeRAID which is probably bouncing for
the HIGHMEM pages in most if not all of the tests so results will
likely improve when bouncing is eliminated.  Need to work this problem next.

2419     = 2.4.19 + o(1) scheduler
2419rmap = 2.4.19 + rmap14b + o(1) scheduler

%sys/%user = ratio of %system CPU utilization to %user CPU utilization.