2002-01-30 10:17:27

by Andrea Arcangeli

[permalink] [raw]
Subject: 2.4.18pre7aa1

kernel.org seems down at the moment so I temporarily uploaded it here
(as soon as kernel.org is back, it will be automatically there as well
in the usual place of course).

ftp://ftp.suse.com/pub/people/andrea/kernel-patches/2.4/2.4.18pre7aa1.gz (single patch)
ftp://ftp.suse.com/pub/people/andrea/kernel-patches/2.4/2.4.18pre7aa1.tar.gz (collection)

(btw, really while I'm writing this email, the two above files are not
yet available on suse.com either yet but they should become visible very
soon, so if you don't see them immediatly it's normal)

the pte-highmem stuff seems quite solid now (the design that killed the
series was too slow and complex, so I preferred to deal with the
ordering instead and to be fast in the fast paths like reading the same
page a few times in the pagecache).

I will try to concentrate on some merging with Marcelo (in particular
the vm bits hoping he agress with them) and to forward port some stuff
(notably pte-highmem) to 2.5 for Linus in the next days/weeks (plus
fixing pte-highmem on the non x86 archs at least for 2.4).

changelog:

Only in 2.4.18pre4aa1: 00_3.5G-address-space-3
Only in 2.4.18pre7aa1/: 00_3.5G-address-space-4

Add 3/2/1G option with PAE enabled (3.5G isn't feasible with PAE).
From Hugh Dickins.

Only in 2.4.18pre7aa1/: 00_VM_IO-fbmem-1

Cleanup the VM_IO points in the framebuffer drivers.
From Andrew Morton.

Only in 2.4.18pre4aa1: 00_access_process_vm-1

Obsoleted by the more generic 00_get_user_pages-1 fix.

Only in 2.4.18pre4aa1: 00_allow_mixed_b_size-1

Dropped in favour of vary-io. (vary-io core with this patch wouldn't
perform optimally due additional non mergeable requests with only a
small b_size in them)

Only in 2.4.18pre7aa1/: 00_alpha-extern-inline-1

Use static inline for new compilers.

Only in 2.4.18pre4aa1: 00_block-highmem-all-18b-2.bz2
Only in 2.4.18pre7aa1/: 00_block-highmem-all-18b-2.gz
Only in 2.4.18pre4aa1: 00_netconsole-2.4.10-C2-2.bz2
Only in 2.4.18pre7aa1/: 00_netconsole-2.4.10-C2-2.gz
Only in 2.4.18pre4aa1: 60_tux-2.4.17-final-A0.bz2
Only in 2.4.18pre7aa1/: 60_tux-2.4.17-final-A0.gz

Stop uploading .bz2 files according to the kernel.org policy.

Only in 2.4.18pre7aa1/: 00_get_user_pages-1

Fix map_user_kiobuf/O_DIRECT and friends, fail
the get_user_pages if one page in the mapping is non RAM.
From Andrew Morton.

Only in 2.4.18pre4aa1: 00_icmp-offset-1

Dropped (not needed).

Only in 2.4.18pre4aa1: 00_lvm-1.0.1-rc4-6.bz2
Only in 2.4.18pre7aa1/: 00_lvm-1.0.2-1.gz

Upgrade to lvm 1.0.2 from sistina.com.

Only in 2.4.18pre7aa1/: 00_netfilter-missing-1

A few missing files from a netfilter update. Posted by David Miller on
l-k.

Only in 2.4.18pre4aa1: 00_o_direct-leftovers-2

Merged in mainline.

Only in 2.4.18pre4aa1: 00_rcu-poll-3
Only in 2.4.18pre7aa1/: 00_rcu-poll-4

Dipankar Sarma raised a good point about enabling the true rcu also in
UP, if the call_rcu is run from interrupt, having the rcu enabled in UP
avoids the reader side to clear irqs. Patch update from Dipankar.

Only in 2.4.18pre4aa1: 00_waitfor-one-page-1

Equivalent in mainline.

Only in 2.4.18pre4aa1: 10_lvm-incremental-2
Only in 2.4.18pre4aa1: 10_lvm-snapshot-hardsectsize-2

Merged into the 1.0.2 Sistina update.

Only in 2.4.18pre4aa1: 10_nfs-o_direct-1
Only in 2.4.18pre7aa1/: 10_nfs-o_direct-2

Rediffed. (also changed one line to use the host inode in the mapping)

Only in 2.4.18pre7aa1/: 10_rawio-vary-io-1

rawio improvement to try to use a 4k b_size (rather than the usual
512byte hardblocksize) on large buffers. Patch from Badari Pulavarty.
So far the feature is enabled only for aic7xxx (new) and qlogicisp.

Only in 2.4.18pre7aa1/: 10_try-cciss-only-4G-1

Let's try if this helps fixing the cciss instability with block-highmem
on a 16G box (I suspect the controller needs to be triggered into DAC
mode somehow, just writing the high 32bits of the bus address may not
be enough, just guessing, and if something this patch cannot
destabilize it further).

Only in 2.4.18pre4aa1: 10_vm-23
Only in 2.4.18pre7aa1/: 10_vm-24

Made a bit more aggressive and less likely to swap.

Only in 2.4.18pre7aa1/: 20_balance-dirty-wait-1

Merged a few async flushing changes from rmap12a. Arjan, can you test
if you still get a write slowdown with this patch too? If yes, the only
other place that can matter is sync_page_buffers, but that should be
slower in rmap. However I wonder if this diff will slowdown a workload
ala dbench.

Only in 2.4.18pre7aa1/: 20_pte-highmem-10
Only in 2.4.18pre4aa1: 20_pte-highmem-6

New version of pte-highmem. Fixed lots of bugs, should be solid now. To
compile the current -aa tree on alpha you've to backout pte-highmem-10
first (I also just updated it partially for alpha, and infact it
compiles but it also later crashes at boot so it's clearly not finished
yet on the alpha update side :).

Only in 2.4.18pre4aa1: 30_dyn-sched-3
Only in 2.4.18pre7aa1/: 30_dyn-sched-4

Fixup a compile trouble with the numa scheduler enabled.

Only in 2.4.18pre4aa1: 50_uml-patch-2.4.17-7.bz2
Only in 2.4.18pre7aa1/: 50_uml-patch-2.4.17-9.gz

Upgrade to latest update on user-mode-linux.sourceforge.net from Jeff.

Andrea


2002-01-30 17:55:48

by Hugh Dickins

[permalink] [raw]
Subject: [PATCH] 18pre7aa1 pagetable corroops

clear_pagetable corrupts memory and oopses when CONFIG_HIGHMEM,
but the pagetable has been allocated from low memory.

Hugh

--- 2.4.18-pre7aa1/include/linux/highmem.h Wed Jan 30 15:30:21 2002
+++ linux/include/linux/highmem.h Wed Jan 30 15:30:21 2002
@@ -103,7 +103,7 @@
{
void * vaddr = kmap_pagetable(page);
clear_page(vaddr);
- kunmap_high(vaddr);
+ kunmap_vaddr((unsigned long)vaddr);
}

/*

2002-01-30 20:27:07

by Andrea Arcangeli

[permalink] [raw]
Subject: Re: [PATCH] 18pre7aa1 pagetable corroops

On Wed, Jan 30, 2002 at 05:55:38PM +0000, Hugh Dickins wrote:
> clear_pagetable corrupts memory and oopses when CONFIG_HIGHMEM,
> but the pagetable has been allocated from low memory.

right, thanks. BTW, I kept the other fixmap_init code beause of the many
more BUG() checks (like the PTRS_PER_PMD checks with PAE) and because
it is equivalent after all.

Andrea

2002-01-30 21:21:09

by Hugh Dickins

[permalink] [raw]
Subject: Re: [PATCH] 18pre7aa1 pagetable corroops

On Wed, 30 Jan 2002, Andrea Arcangeli wrote:
>
> right, thanks. BTW, I kept the other fixmap_init code beause of the many
> more BUG() checks (like the PTRS_PER_PMD checks with PAE) and because
> it is equivalent after all.

No, not equivalent, see other mail. Do add BUG()s to mine if you like,
but they've not served well so far, and are not very helpful that early:
more a sign of insecurity.

Hugh

2002-01-31 00:43:07

by Randy Hron

[permalink] [raw]
Subject: Re: 2.4.18pre7aa1

Historical changelog for 2.4.18pre7aa1 at:
http://home.earthlink.net/~rwhron/kernel/2.4.18pre7aa1.html

Benchmarks on 2.4.18pre7aa1 and other kernels at:
http://home.earthlink.net/~rwhron/kernel/k6-2-475.html

On Fri, Jan 25, 2002 at 06:29:01PM +0100, Dave Jones wrote:
> > The -aa kernel seems to contain patches to a few dozen subsystems.
>
> Agreed. Andrea's tree seemed to gain quite a bit of a lead
> when bits of the lowlat patches were applied for eg.
> Just taking 00_vm_?? from ../people/andrea/.. would give better
> comparison

Several of Andrea's patches touch the core VM files. Deciding
what to include, and the order to apply them would take some
effort, know how, and good judgement.

If someone provides a list of the patches to apply in the
proper order, I will run the tests.

--
Randy Hron

2002-01-30 23:38:21

by Andrea Arcangeli

[permalink] [raw]
Subject: Re: [PATCH] 18pre7aa1 pagetable corroops

On Wed, Jan 30, 2002 at 09:23:12PM +0000, Hugh Dickins wrote:
> On Wed, 30 Jan 2002, Andrea Arcangeli wrote:
> >
> > right, thanks. BTW, I kept the other fixmap_init code beause of the many
> > more BUG() checks (like the PTRS_PER_PMD checks with PAE) and because
> > it is equivalent after all.
>
> No, not equivalent, see other mail. Do add BUG()s to mine if you like,
> but they've not served well so far, and are not very helpful that early:
> more a sign of insecurity.

I don't agree they're a sign of insecurity, I think it's the other way
around. anyways I'll check your other email in detail now, thanks.

Andrea