lkml.org 
[lkml]   [2001]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.4.10pre13aa1
The VM seems now solid and effient but still it will be interesting to hear
details about any prossible regression or instability (also Linus has ideas on
things to change in such area).

I probably won't release any further -aa patchkit until 25 Sep but I'll try to
be responsive for anything very urgent. (I'll queue all low prio emails for
next week)

Only in 2.4.10pre12aa1: 00_compile-sysrq-1
Only in 2.4.10pre12aa1: 00_shrink_cache-BUG-1
Only in 2.4.10pre12aa1: 00_swap-writepage-1
Only in 2.4.10pre12aa1: 00_swapin-wrprotect-1
Only in 2.4.10pre12aa1: 00_swapout-1
Only in 2.4.10pre12aa1: 00_vm-writepage-reference-1

Merged in mainline.

Only in 2.4.10pre12aa1: 00_GFP_ATOMIC-1
Only in 2.4.10pre13aa1: 00_GFP_ATOMIC-2

The important part of it merged in mainline, left only the lowering of
the ATOMIC low watermark (to increase the ATOMIC GAP).

Only in 2.4.10pre13aa1: 00_debug-gfp-1

Replaced the __builtin_return_address(0) in GFP with a show_stack if
CONFIG_DEBUG_GFP is defined. (the caller was going to be in the mm so
__builtin_return_address(0) was useless).

Only in 2.4.10pre12aa1: 00_flush-inode-reschedule-1
Only in 2.4.10pre13aa1: 00_flush-inode-reschedule-2

Include compiler.h.

Only in 2.4.10pre12aa1: 00_highmem-debug-2

Rediffed.

Only in 2.4.10pre12aa1: 00_ramdisk-secure-1
Only in 2.4.10pre12aa1: 00_ramdisk-secure-1-const-1
Only in 2.4.10pre13aa1: 00_ramdisk-secure-2

Fixed ramdisk-secure, now it has its own address space operations. When
used as a blkdev it now with works like ramfs internally. In turn
initrd works again.

Only in 2.4.10pre13aa1: 00_reiserfs-IO-1

Mark the buffer referenced when making it visible to the VM so it's
more likley that it won't be collected away before we have a chance to
allocate it (getblk/grow_buffers interaction should be fixed but this
is a simple one liner for now).

Only in 2.4.10pre12aa1: 00_rwsem-fair-20-recursive-1
Only in 2.4.10pre13aa1: 00_rwsem-fair-20-recursive-2

Rediffed (only needed for core dumping now).

Only in 2.4.10pre13aa1: 00_start-aggressive-readahead-1

XFS needs to know when it can do possibly wasteful aggressive
readhaead (it doesn't want to shrink caches to make space
for the possibly wasteful readahead). This new VM call will provide
this information. Other fs are free to use it too of course.

Only in 2.4.10pre13aa1: 00_unmap-dirty-pte-1

I grepped over the whole 600 pages of the latest x86 system developer
manual and I couldn't find the proof that I'm wrong.

We can have pagecache pages with pte writeable and non dirty at some
point.

Now what happens if the userspace task in the other cpu touches the
writeable page between our "ptep_get_and_clear" and the
"flush_tlb_page"? Is the resulting pte still zero and the task get into
a page fault? Or as I am worried it could also just end with the pte
with only the dirty bit set? Does somebody know for sure? I can
imagine the cpu finding the tlb state writeable, and issuing just a
locked bit test and set in the pte without caring to check if the pte
is zero or not.

If the cpu just set the bit this patch will avoid to lose a shared
mapping update. Otherwise it's a safe noop so I keep it applied
until this issue is sorted out.

Only in 2.4.10pre13aa1: 00_vmalloc-cache-flush-1

Reintroduced the cache flush in vmalloc, (not the tlb flush) per DaveM
request. Noop for x86/alpha.

Only in 2.4.10pre13aa1: 10_highmem-debug-3

Rediffed.

Only in 2.4.10pre13aa1: 10_numa-sched-10
Only in 2.4.10pre12aa1: 10_numa-sched-9

Rediffed, now it compiles :).

Only in 2.4.10pre12aa1: 50_uml-patch-2.4.9-6.bz2
Only in 2.4.10pre13aa1: 50_uml-patch-2.4.9-7-1.bz2

Picked last uml update from sourceforge.

Only in 2.4.10pre12aa1: 53_uml-gcc-3.0-1

Merged in mainline -7 revision.

Only in 2.4.10pre13aa1: 57_ptrace_disable-1
Only in 2.4.10pre13aa1: 58_uml-tlb-1

Allow uml compilation, tlb.h copied from 2.4.9ac12.

Only in 2.4.10pre12aa1: 60_atomic-alloc-5
Only in 2.4.10pre13aa1: 60_atomic-alloc-6

Rediffed (now USEDFPU is defined only once :).

Only in 2.4.10pre12aa1: 60_tux-2.4.9-ac10-J4
Only in 2.4.10pre13aa1: 60_tux-2.4.9-ac10-J9

Picked last update from www.redhat.com/~mingo/ .

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.079 / U:14.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site