Marcelo, can you merge the loop-deadlock fix? (the others aren't
trivially mergeable yet and for the tcp conntrack you'd need to ask
Rusty first, the change is simple enough that I merged it for now)
Andrew, could you give it a spin to verify I/O performance is back? It
is fast for me now.
Only in 2.4.17rc1aa1: 00_block-highmem-all-18b-2.bz2
Only in 2.4.17pre4aa1: 00_block-highmem-all-18b.bz2
Only in 2.4.17pre4aa1: 00_flush_icache_range-1
Only in 2.4.17rc1aa1: 00_flush_icache_range-2
Only in 2.4.17pre4aa1: 00_silent-stack-overflow-12
Only in 2.4.17rc1aa1: 00_silent-stack-overflow-13
Only in 2.4.17pre4aa1: 00_spinlock-cacheline-2
Only in 2.4.17rc1aa1: 00_spinlock-cacheline-3
Only in 2.4.17pre4aa1: 10_numa-sched-14
Only in 2.4.17rc1aa1: 10_numa-sched-15
Only in 2.4.17pre4aa1: 60_atomic-alloc-6
Only in 2.4.17rc1aa1: 60_atomic-alloc-7
Only in 2.4.17pre4aa1: 00_rwsem-fair-25-recursive-6
Only in 2.4.17rc1aa1: 00_rwsem-fair-25-recursive-7
Not used actively anymore for the coredump (we walk the pagetables
by hand instead of using the MMU now).
Only in 2.4.17rc1aa1: 00_loop-deadlock-1
Fixed loop deadlock (balance_dirty() must not be called within the
request_fn or it can deadlock or recurse way too much). It is
enough to recall balance_dirty() at the highest layer so this won't
introduce any stability problem.
Only in 2.4.17rc1aa1: 00_tcp-conntrack-fin-1
After upgrading my firewall/NAT to 2.4 (s/ipchains/iptables/ :) I started
getting valid tcp packets dropped/logged (I'm allowing only RELATED and
ESTABLISHED packets from the outside, with ipchains I was allowing all
tcp packets that weren't syn and there weren't problems). Rusty sent me
the above fix to see if my problem with the tcp connection tracking
goes away (without adding again the rule that all non tcp syn can came in).
Only in 2.4.17pre4aa1: 10_vm-19
Only in 2.4.17rc1aa1: 10_vm-20
Should fix the I/O async flushing performance drop reported by Andrew.
Cannot += BUF_LOCKED any longer in balance_dirty because we don't waste
time any longer refiling clean buffers into the BUF_CLEAN now (sync has to
pass all over the bh anyways so it doesn't matter for it either).
Avoid collapsing the max_mapped during shrink_cache internal passes.
Only in 2.4.17pre4aa1: 50_uml-patch-2.4.15-3.bz2
Only in 2.4.17rc1aa1: 50_uml-patch-2.4.16-2.bz2
Latest update from Jeff at user-mode-linux.sourceforge.net.
Only in 2.4.17pre4aa1: 60_tux-2.4.16-final-C9.bz2
Only in 2.4.17rc1aa1: 60_tux-2.4.16-final-D5.bz2
Latest update from Ingo at www.redhat.com/~mingo/.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:28 EST