This is the first release moving the pagetables in highmem. It only
compiles on x86 and it is still a bit experimental. I couldn't reproduce
problems yet though. the new pte-highmem patch can be downloaded from
here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/20_pte-highmem-6
Next relevant things to do are the non-x86 archs compilation, and I'd
like to sort out the vary-IO for rawio and the hardblocksize-O_DIRECT
patch.
URL:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/
Diff between 2.4.18pre2aa2 and 2.4.18pre4aa1 follows:
Only in 2.4.18pre2aa2: 00_3.5G-address-space-2
Only in 2.4.18pre4aa1/: 00_3.5G-address-space-3
Merge 1-2-3 GB option.
Only in 2.4.18pre4aa1/: 00_access_process_vm-1
Fix oops in access_process_vm (get_area_pages will
set the page pointer to NULL on non-ram maps).
Only in 2.4.18pre4aa1/: 00_allow_mixed_b_size-1
This is the groundwork for the O_DIRECT-hardblocksize
patch, and for the IOvary patch for rawio.
In short this prevents the merging of different b_size
in the same request at the blkdev layer. After I mentioned
this Jens immediatly sent me a patch and here it is.
So now I'd suggest to drop the varyIO thing which shouldn't
be necessary any longer, and to port the rawio-large-bsize
patch, and the O_DIRECT hardblocksize patches on top of
my current tree. I'd like to include both. Of course the
O_DIRECT-hardblocksize patch can also take advantage of
the large-b_size improvement to brw_kiovec during large
requests hardblocksize aligned. At least unless we want
to change the alignment requirements, in such a case
the varyIO info would be still valuable.
About the O_DIRECT-hardblocksize patch there's also another problem
though, if the get_block says that the buffer is new(), then
the whole "soft" block must be cleared out, if not written
to completly implicitly by the write. I just fixed similar bugs in
presence of I/O errors or ENOSPC with O_DIRECT, and I don't want to
reintroduce the very same problem while adding a new feature. The
buffer_new() path is a very slow path for the DB usage point of view,
so it's perfectly fine there to just writeout the zero page (or
something like that) on the blocks around in a synchronous manner etc..
Only in 2.4.18pre4aa1/: 00_icmp-offset-1
Remote security fix from Andi (see bugtraq).
Only in 2.4.18pre4aa1/: 00_init-blk-freelist-1
Requests cmd wasn't initialized when first queued into the blkdev,
so if dequeued and then re-enqueued without being used, they could get
unbalanced. Now always initialize it during get_request, so it certainly
works right.
Only in 2.4.18pre2aa2: 00_msync-ret-1
Only in 2.4.18pre2aa2: 00_page-cache-release-1
Only in 2.4.18pre2aa2: 00_ramdisk-buffercache-2
Only in 2.4.18pre2aa2: 00_truncate-garbage-1
Merged in mainline.
Only in 2.4.18pre2aa2: 00_vmalloc-tlb-flush-1
Merged into mainline (modulo Jeff having implemented pagetable
walking/tlb misses into uml that doesn't assume the tlb
flush [ouch, right Andrew, tlb invalidate :) ] cames first).
Only in 2.4.18pre2aa2: 00_nfs-2.4.17-cto-1
Only in 2.4.18pre4aa1/: 00_nfs-2.4.17-cto-2
Only in 2.4.18pre2aa2: 00_nfs-bkl-1
Only in 2.4.18pre4aa1/: 00_nfs-bkl-2
Only in 2.4.18pre2aa2: 00_nfs-rdplus-1
Only in 2.4.18pre4aa1/: 00_nfs-rdplus-2
Only in 2.4.18pre2aa2: 00_nfs-svc_tcp-1
Only in 2.4.18pre4aa1/: 00_nfs-svc_tcp-2
Only in 2.4.18pre2aa2: 00_nfs-tcp-tweaks-1
Only in 2.4.18pre4aa1/: 00_nfs-tcp-tweaks-2
Only in 2.4.18pre4aa1/: 10_nfs-o_direct-1
New NFS updates from Trond.
Only in 2.4.18pre2aa2: 00_rwsem-fair-25
Only in 2.4.18pre2aa2: 00_rwsem-fair-25-recursive-7
Only in 2.4.18pre4aa1/: 00_rwsem-fair-26
Only in 2.4.18pre4aa1/: 00_rwsem-fair-26-recursive-7
Rediffed.
Only in 2.4.18pre4aa1/: 00_waitfor-one-page-1
Export complaining symbol.
Only in 2.4.18pre2aa2: 10_vm-22
Only in 2.4.18pre4aa1/: 10_vm-23
Minor changes (try to always do some relevant work during the
refiling).
Only in 2.4.18pre4aa1/: 20_pte-highmem-6
First "working" version of the pte-highmem patch, this fixes (or at
least "should fix" :) lots of bugs. pte_offset_lowmem is still there
because kmap doesn't yet work by the time pte_offset_lowmem is
recalled. Lots of fixes, special thanks to Hugh, Linus and others for
the review and the feedback! All drivers should be updated. Works
for me so far.
Only in 2.4.18pre2aa2: 30_dyn-sched-2
Only in 2.4.18pre4aa1/: 30_dyn-sched-3
Minor changes, volatile would be needed only to avoid confusing
gcc, but nobody cares about variables changing under gcc anyways so
let's remove it so it will be a little faster.
Only in 2.4.18pre2aa2: 50_uml-patch-2.4.17-4.bz2
Only in 2.4.18pre4aa1/: 50_uml-patch-2.4.17-7.bz2
Latest update from Jeff (hopefully vmalloc works despite it doesn't
start with the tlb invalidate).
Only in 2.4.18pre4aa1/: 60_show-stack-1
Export symbol, so CONFIG_TUX_DEBUG has a chance to generate a loadable
kernel module.
Only in 2.4.18pre2aa2: 60_tux-vfs-4
Only in 2.4.18pre4aa1/: 60_tux-vfs-5
Rediffed.
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/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:52 EST