2.4.23pre6aa1
Subsystems (2)
URL:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1.gz http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1/
Probably the most notable new feature is that you can now pass 'desktop' as parameter to the kernel in lilo to ask the kernel to behave optimally for a desktop machine. No need of compile time options anymore. For more experienced users HZ=500/HZ=50/HZ=200 should work fine too, then you can tune the timeslices by hand but you must know what you're doing.
You can verify everything went well after boot with:
cat /proc/sys/kernel/{*timeslice,HZ}This kernel seems to boot fine again on x86-64 too. The merges in pre6 were helpful.
Due the amount of changes you may not want to run this on any production box (note: not because of the dynamic-hz feature, but because of everything else, the dynamic-hz is the only one that has no way to break anything, modulo stuff that would break anyways on ia64 and alpha already and that you can workaround trivially with HZ=100 if needed).
Only in 2.4.22aa1: 00_config-smp-1
Only in 2.4.22aa1: 00_copy-namespace-1
Only in 2.4.22aa1: 00_panic-console-switch-1 Only in 2.4.22aa1: 00_pgt-cache-leak-2
Only in 2.4.22aa1: 00_read_full_page-get_block-err-2 Only in 2.4.22aa1: 00_sk98lin_2.4.22-20030902-1.gz Only in 2.4.22aa1: 05_vm_03_vm_tunables-4 Only in 2.4.22aa1: 05_vm_05_zone_accounting-2 Only in 2.4.22aa1: 05_vm_06_swap_out-3
Only in 2.4.22aa1: 05_vm_07_local_pages-4 Only in 2.4.22aa1: 05_vm_09_misc_junk-3
Only in 2.4.22aa1: 05_vm_16_active_free_zone_bhs-1 Only in 2.4.22aa1: 05_vm_20_cleanups-3
Only in 2.4.22aa1: 9999900_request-firmware-1
Merged in mainline.
Only in 2.4.22aa1: 00_cpu-affinity-syscall-rml-4
Only in 2.4.23pre6aa1: 00_cpu-affinity-syscall-rml-5 Only in 2.4.22aa1: 00_extraversion-29
Only in 2.4.23pre6aa1: 00_extraversion-30
Only in 2.4.22aa1: 00_global-irq-race-1
Only in 2.4.23pre6aa1: 00_global-irq-race-2
Only in 2.4.22aa1: 00_rwsem-fair-38
Only in 2.4.22aa1: 00_rwsem-fair-38-recursive-8
Only in 2.4.23pre6aa1: 00_rwsem-fair-39
Only in 2.4.23pre6aa1: 00_rwsem-fair-39-recursive-8 Only in 2.4.22aa1: 00_silent-stack-overflow-18
Only in 2.4.23pre6aa1: 00_silent-stack-overflow-19 Only in 2.4.22aa1: 00_x86-optimize-apic-irq-and-cacheline-2 Only in 2.4.23pre6aa1: 00_x86-optimize-apic-irq-and-cacheline-3 Only in 2.4.22aa1: 05_vm_22_vm-anon-lru-1
Only in 2.4.23pre6aa1: 05_vm_22_vm-anon-lru-2
Only in 2.4.22aa1: 05_vm_17_rest-10
Only in 2.4.23pre6aa1: 05_vm_26-rest-1
Only in 2.4.22aa1: 05_vm_23_per-cpu-pages-3
Only in 2.4.23pre6aa1: 05_vm_23_per-cpu-pages-4
Only in 2.4.22aa1: 05_vm_24_accessed-ipi-only-smp-1 Only in 2.4.22aa1: 10_lvm-snapshot-check-3
Only in 2.4.23pre6aa1: 10_lvm-snapshot-check-4
Only in 2.4.23pre6aa1: 20_rcu-poll-10
Only in 2.4.22aa1: 20_rcu-poll-9
Only in 2.4.22aa1: 30_irq-balance-15
Only in 2.4.23pre6aa1: 30_irq-balance-16
Only in 2.4.22aa1: 60_net-exports-3
Only in 2.4.23pre6aa1: 60_net-exports-4
Only in 2.4.22aa1: 60_tux-syscall-5
Only in 2.4.23pre6aa1: 60_tux-syscall-6
Only in 2.4.22aa1: 60_tux-sysctl-3
Only in 2.4.23pre6aa1: 60_tux-sysctl-4
Only in 2.4.22aa1: 90_proc-mapped-base-5
Only in 2.4.23pre6aa1: 90_proc-mapped-base-6
Only in 2.4.22aa1: 93_NUMAQ-13
Only in 2.4.23pre6aa1: 93_NUMAQ-14
Only in 2.4.22aa1: 96_inode_read_write-atomic-8
Only in 2.4.23pre6aa1: 96_inode_read_write-atomic-9 Only in 2.4.22aa1: 9900_aio-23.gz
Only in 2.4.23pre6aa1: 9900_aio-24.gz
Only in 2.4.22aa1: 9903_aio-22-ppc-1
Only in 2.4.23pre6aa1: 9903_aio-22-ppc-2
Only in 2.4.22aa1: 9910_shm-largepage-16.gz
Only in 2.4.23pre6aa1: 9910_shm-largepage-17.gz
Only in 2.4.22aa1: 9920_kgdb-11.gz
Only in 2.4.23pre6aa1: 9920_kgdb-12.gz
Only in 2.4.22aa1: 9925_kmsgdump-0.4.4-3.gz
Only in 2.4.23pre6aa1: 9925_kmsgdump-0.4.4-4.gz
Only in 2.4.22aa1: 9950_futex-5.gz
Only in 2.4.23pre6aa1: 9950_futex-6.gz
Only in 2.4.22aa1: 9999_sched_yield_scale-6
Only in 2.4.23pre6aa1: 9999_sched_yield_scale-8
Only in 2.4.22aa1: 9999901_scsi-softirq-2
Only in 2.4.23pre6aa1: 9999901_scsi-softirq-3
Only in 2.4.22aa1: 9999900_ecc-20030225-1.gz
Only in 2.4.23pre6aa1: 9999900_ecc-20030225-2.gz
Only in 2.4.22aa1: 9999900_ikd-2.gz
Only in 2.4.23pre6aa1: 9999900_ikd-4.gz
Only in 2.4.22aa1: 9999900_ipc-rcu-1
Only in 2.4.23pre6aa1: 9999900_ipc-rcu-2
Only in 2.4.22aa1: 9999900_monitor-mwait-1
Only in 2.4.23pre6aa1: 9999900_monitor-mwait-2
Rediffed.
Only in 2.4.23pre6aa1: 00_do_brk-1
glitch fixup from Andrew.
Only in 2.4.23pre6aa1: 00_e-nodev-1
s/NODEV/ENODEV/ fixes from Vojtech.
Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
Add missing smb_mb().
Only in 2.4.22aa1: 00_log-buf-len-1
Only in 2.4.23pre6aa1: 00_log-buf-len-dynamic-1
Ported to 2.4.23pre6 to allow the configuration of the buffer size at compile time too.
Only in 2.4.23pre6aa1: 00_proc-readlink-1
Remeber to free tmp buffer (from spender)
Only in 2.4.22aa1: 00_sched-O1-aa-2.4.19rc3-17.gz Only in 2.4.23pre6aa1: 00_sched-O1-aa-2.4.19rc3-18.gz
Let the idle load_balance pass to pick any task it find, if we go idle it means we've no task left. This fix speeds up number crunching up to 100% in some arch. The very same fix incidentally is also present in current 2.6.
Only in 2.4.23pre6aa1: 00_sk98lin-char-fix-1
Count the right number of bytes (not ints).
Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
Don't take the bkl (the same paths runs w/o the bkl elsewhere), from Chris Mason.
Only in 2.4.23pre6aa1: 01_softirq-nowait-1
We must really keep executing softirqs or it may take a too long time before ksoftirqd gets some cpu time. For an embedded device you may want to remove this, on a server we need this still.
Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
This fixes a longstanding bug for a number of archs that haven't the dirty bit updated in hardware. For those archs we can't mark the pte writeable when it's still in swap cache, unless we don't mark it dirty too at the same time. Otherwise the cpu will go ahead writing to the page, no fault will happen and the swapcache will be still clean, and the data will be lost at the next zeroIO swapout leading to userspace data corruption and segfaults during swap. Affected archs are alpha/s390/s390x for example.
This bug was specific to the -aa VM, it couldn't happen in mainline. In my tree I optimized the code to exploited properties of archs that updates the bit in hardware for the first time. Hence the first need of a #define to differentiate the two code paths. The logic in the software-dirty-bit case will be less efficient of course (that's why there's a difference in the first place).
This is an obvious noop for x86 and x86-64 for example.
NOTE: the software-dirty-bit code is safe for all archs, the other way around not.
Only in 2.4.23pre6aa1: 30_18-busy-inodes-1
Try to avoid to leave busy inodes in autofs unmount. From Olaf Kirch. (original from Trond).
Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
Ignore errors on exiting lock cleanups. From Trond.
Only in 2.4.22aa1: 70_xfs-1.3-2.gz
Only in 2.4.23pre6aa1: 70_xfs-1.3-3.gz
Only in 2.4.22aa1: 70_xfs-sysctl-3
Only in 2.4.23pre6aa1: 70_xfs13pre-final-1.gz
Only in 2.4.23pre6aa1: 71_qsort-1
Only in 2.4.22aa1: 71_xfs-VM_IO-1
Only in 2.4.22aa1: 71_xfs-aa-4
Only in 2.4.23pre6aa1: 71_xfs-aa-5
Only in 2.4.23pre6aa1: 71_xfs-mmap-1
Only in 2.4.22aa1: 71_xfs-tuning-1
XFS 13pre-final merged.
Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
To really be able to help and not just waste some seek and cpu, wait_on_buffer should honour the BH_Sync, but this is late in 2.4, and so I prefer to get rid of it instead of giving it the full power it should have.
Only in 2.4.23pre6aa1: 9999900_soft-float-1
Trap any usage of the FPU in kernel (needed to trap things like schedule_timeout(HZ*0.1)).
Only in 2.4.22aa1: 9999901_aio-network-poll-pipe-1 Only in 2.4.23pre6aa1: 9999901_aio-poll-2
Leave only the aio-poll functionality because the network aio is still unfinished and nobody needs the pipe one (AFIK).
Only in 2.4.23pre6aa1: 9999_00_x86_64-suse-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-sys-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-tsc-c0-bandaid-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-warning-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-zone-startpfn-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-bigpages-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-export-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-bitops-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-discontig-pmd-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-epoll-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-fault32-wrap-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-kgdb-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-lvm32-no-checks-1
Merge x86-64 updates from Andi Kleen.
Only in 2.4.23pre6aa1: 9999_athlon-errata-prefetch-1
Fix athlon prefetch invalid faults from userspace. From Andi Kleen.
Only in 2.4.23pre6aa1: 9999_z-execve-race-1
Fix race in exit_mmap.
Only in 2.4.23pre6aa1: 9999_z-laptopmode-1
Allow the first read hitting the disk to flush all the dirty buffers. From Jens Axboe.
Only in 2.4.22aa1: 9999900_desktop-4
Only in 2.4.23pre6aa1: 9999_zz-dynamic-timeslice-1 Only in 2.4.23pre6aa1: 9999_zzz-dynamic-hz-1
HZ is now dynamic, you can boot with HZ=50 HZ=100 HZ=500 or HZ=1000. However only HZ=100 and HZ=1000 are supported. Anything different from HZ=100 can trigger device driver bugs (those would already trigger on ia64 and alpha but on x86 the amount of drivers in use is larger).
But wait, you shouldn't use HZ=, you should only pass 'desktop' if you want to use the machine to behave as a better desktop and the kernel will just do the right thing.
max-timeslice/min-timeslice tunables are also provided as sysctl. Again no need to tune those, just pass 'desktop' if your machine is a desktop.
The scheduler has internal heuristics (the avg_sleep for example in the o1 scheduler) to try to identify the interactive tasks. Since those are heuristics there's also the chance of failing. By rescheduling taks at around 100hz even if the heuristic fails there's quite a good margin before your eye can see it. This should help with video players and games.
Only in 2.4.23pre6aa1: 9999_zzzz-stackoverflow-1
Prevent overflows from happening on top of softirq. From Hugh Dickins.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
I'm getting the below errors compiling the bttv module.
Also, the commercial OSS sound driver fails to compile against it. It compiled under -pre6.
Otherwise, it seems to work fine for me.
Let me know, if you need any further info.
Cheers,
Mathias
make[4]: Entering directory `/usr/src/linux-2.4/drivers/media/video'
gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O4 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -msoft-float -mprefer red-stack-boundary=2 -march=pentium3 -nostdinc -iwithprefix include -DKBUILD_BASENAM E=bttv_cards -c -o bttv-cards.o bttv-cards.cbttv-cards.c: In function `pvr_boot':
bttv-cards.c:2552: structure has no member named dev' bttv-cards.c:2555: warning: implicit declaration of function request_firmware' bttv-cards.c:2559: `rc' undeclared (first use in this function) bttv-cards.c:2559: (Each undeclared identifier is reported only once bttv-cards.c:2559: for each function it appears in.) bttv-cards.c:2561: dereferencing pointer to incomplete type bttv-cards.c:2561: dereferencing pointer to incomplete type bttv-cards.c:2562: warning: implicit declaration of function `release_firmware'
Quoted 287 lines · Andrea Arcangeli
URL:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1.gz http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1/Probably the most notable new feature is that you can now pass 'desktop' as parameter to the kernel in lilo to ask the kernel to behave optimally for a desktop machine. No need of compile time options anymore. For more experienced users HZ=500/HZ=50/HZ=200 should work fine too, then you can tune the timeslices by hand but you must know what you're doing.
You can verify everything went well after boot with:
cat /proc/sys/kernel/{*timeslice,HZ}This kernel seems to boot fine again on x86-64 too. The merges in pre6 were helpful.
Due the amount of changes you may not want to run this on any production box (note: not because of the dynamic-hz feature, but because of everything else, the dynamic-hz is the only one that has no way to break anything, modulo stuff that would break anyways on ia64 and alpha already and that you can workaround trivially with HZ=100 if needed).
Only in 2.4.22aa1: 00_config-smp-1
Only in 2.4.22aa1: 00_copy-namespace-1
Only in 2.4.22aa1: 00_panic-console-switch-1 Only in 2.4.22aa1: 00_pgt-cache-leak-2
Only in 2.4.22aa1: 00_read_full_page-get_block-err-2 Only in 2.4.22aa1: 00_sk98lin_2.4.22-20030902-1.gz Only in 2.4.22aa1: 05_vm_03_vm_tunables-4 Only in 2.4.22aa1: 05_vm_05_zone_accounting-2 Only in 2.4.22aa1: 05_vm_06_swap_out-3
Only in 2.4.22aa1: 05_vm_07_local_pages-4 Only in 2.4.22aa1: 05_vm_09_misc_junk-3
Only in 2.4.22aa1: 05_vm_16_active_free_zone_bhs-1 Only in 2.4.22aa1: 05_vm_20_cleanups-3
Only in 2.4.22aa1: 9999900_request-firmware-1Merged in mainline.
Only in 2.4.22aa1: 00_cpu-affinity-syscall-rml-4
Only in 2.4.23pre6aa1: 00_cpu-affinity-syscall-rml-5 Only in 2.4.22aa1: 00_extraversion-29
Only in 2.4.23pre6aa1: 00_extraversion-30
Only in 2.4.22aa1: 00_global-irq-race-1
Only in 2.4.23pre6aa1: 00_global-irq-race-2
Only in 2.4.22aa1: 00_rwsem-fair-38
Only in 2.4.22aa1: 00_rwsem-fair-38-recursive-8
Only in 2.4.23pre6aa1: 00_rwsem-fair-39
Only in 2.4.23pre6aa1: 00_rwsem-fair-39-recursive-8 Only in 2.4.22aa1: 00_silent-stack-overflow-18
Only in 2.4.23pre6aa1: 00_silent-stack-overflow-19 Only in 2.4.22aa1: 00_x86-optimize-apic-irq-and-cacheline-2 Only in 2.4.23pre6aa1: 00_x86-optimize-apic-irq-and-cacheline-3 Only in 2.4.22aa1: 05_vm_22_vm-anon-lru-1
Only in 2.4.23pre6aa1: 05_vm_22_vm-anon-lru-2
Only in 2.4.22aa1: 05_vm_17_rest-10
Only in 2.4.23pre6aa1: 05_vm_26-rest-1
Only in 2.4.22aa1: 05_vm_23_per-cpu-pages-3
Only in 2.4.23pre6aa1: 05_vm_23_per-cpu-pages-4
Only in 2.4.22aa1: 05_vm_24_accessed-ipi-only-smp-1 Only in 2.4.22aa1: 10_lvm-snapshot-check-3
Only in 2.4.23pre6aa1: 10_lvm-snapshot-check-4
Only in 2.4.23pre6aa1: 20_rcu-poll-10
Only in 2.4.22aa1: 20_rcu-poll-9
Only in 2.4.22aa1: 30_irq-balance-15
Only in 2.4.23pre6aa1: 30_irq-balance-16
Only in 2.4.22aa1: 60_net-exports-3
Only in 2.4.23pre6aa1: 60_net-exports-4
Only in 2.4.22aa1: 60_tux-syscall-5
Only in 2.4.23pre6aa1: 60_tux-syscall-6
Only in 2.4.22aa1: 60_tux-sysctl-3
Only in 2.4.23pre6aa1: 60_tux-sysctl-4
Only in 2.4.22aa1: 90_proc-mapped-base-5
Only in 2.4.23pre6aa1: 90_proc-mapped-base-6
Only in 2.4.22aa1: 93_NUMAQ-13
Only in 2.4.23pre6aa1: 93_NUMAQ-14
Only in 2.4.22aa1: 96_inode_read_write-atomic-8
Only in 2.4.23pre6aa1: 96_inode_read_write-atomic-9 Only in 2.4.22aa1: 9900_aio-23.gz
Only in 2.4.23pre6aa1: 9900_aio-24.gz
Only in 2.4.22aa1: 9903_aio-22-ppc-1
Only in 2.4.23pre6aa1: 9903_aio-22-ppc-2
Only in 2.4.22aa1: 9910_shm-largepage-16.gz
Only in 2.4.23pre6aa1: 9910_shm-largepage-17.gz
Only in 2.4.22aa1: 9920_kgdb-11.gz
Only in 2.4.23pre6aa1: 9920_kgdb-12.gz
Only in 2.4.22aa1: 9925_kmsgdump-0.4.4-3.gz
Only in 2.4.23pre6aa1: 9925_kmsgdump-0.4.4-4.gz
Only in 2.4.22aa1: 9950_futex-5.gz
Only in 2.4.23pre6aa1: 9950_futex-6.gz
Only in 2.4.22aa1: 9999_sched_yield_scale-6
Only in 2.4.23pre6aa1: 9999_sched_yield_scale-8
Only in 2.4.22aa1: 9999901_scsi-softirq-2
Only in 2.4.23pre6aa1: 9999901_scsi-softirq-3
Only in 2.4.22aa1: 9999900_ecc-20030225-1.gz
Only in 2.4.23pre6aa1: 9999900_ecc-20030225-2.gz
Only in 2.4.22aa1: 9999900_ikd-2.gz
Only in 2.4.23pre6aa1: 9999900_ikd-4.gz
Only in 2.4.22aa1: 9999900_ipc-rcu-1
Only in 2.4.23pre6aa1: 9999900_ipc-rcu-2
Only in 2.4.22aa1: 9999900_monitor-mwait-1
Only in 2.4.23pre6aa1: 9999900_monitor-mwait-2Rediffed.
Only in 2.4.23pre6aa1: 00_do_brk-1
glitch fixup from Andrew.
Only in 2.4.23pre6aa1: 00_e-nodev-1
s/NODEV/ENODEV/ fixes from Vojtech.
Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
Add missing
smb_mb().Only in 2.4.22aa1: 00_log-buf-len-1
Only in 2.4.23pre6aa1: 00_log-buf-len-dynamic-1Ported to 2.4.23pre6 to allow the configuration of the buffer size at compile time too.
Only in 2.4.23pre6aa1: 00_proc-readlink-1
Remeber to free tmp buffer (from spender)
Only in 2.4.22aa1: 00_sched-O1-aa-2.4.19rc3-17.gz Only in 2.4.23pre6aa1: 00_sched-O1-aa-2.4.19rc3-18.gz
Let the idle
load_balancepass to pick any task it find, if we go idle it means we've no task left. This fix speeds up number crunching up to 100% in some arch. The very same fix incidentally is also present in current 2.6.Only in 2.4.23pre6aa1: 00_sk98lin-char-fix-1
Count the right number of bytes (not ints).
Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
Don't take the bkl (the same paths runs w/o the bkl elsewhere), from Chris Mason.
Only in 2.4.23pre6aa1: 01_softirq-nowait-1
We must really keep executing softirqs or it may take a too long time before ksoftirqd gets some cpu time. For an embedded device you may want to remove this, on a server we need this still.
Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
This fixes a longstanding bug for a number of archs that haven't the dirty bit updated in hardware. For those archs we can't mark the pte writeable when it's still in swap cache, unless we don't mark it dirty too at the same time. Otherwise the cpu will go ahead writing to the page, no fault will happen and the swapcache will be still clean, and the data will be lost at the next zeroIO swapout leading to userspace data corruption and segfaults during swap. Affected archs are alpha/s390/s390x for example.
This bug was specific to the -aa VM, it couldn't happen in mainline. In my tree I optimized the code to exploited properties of archs that updates the bit in hardware for the first time. Hence the first need of a #define to differentiate the two code paths. The logic in the software-dirty-bit case will be less efficient of course (that's why there's a difference in the first place).
This is an obvious noop for x86 and x86-64 for example.
NOTE: the software-dirty-bit code is safe for all archs, the other way around not.
Only in 2.4.23pre6aa1: 30_18-busy-inodes-1
Try to avoid to leave busy inodes in autofs unmount. From Olaf Kirch. (original from Trond).
Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
Ignore errors on exiting lock cleanups. From Trond.
Only in 2.4.22aa1: 70_xfs-1.3-2.gz
Only in 2.4.23pre6aa1: 70_xfs-1.3-3.gz
Only in 2.4.22aa1: 70_xfs-sysctl-3
Only in 2.4.23pre6aa1: 70_xfs13pre-final-1.gz
Only in 2.4.23pre6aa1: 71_qsort-1
Only in 2.4.22aa1: 71_xfs-VM_IO-1
Only in 2.4.22aa1: 71_xfs-aa-4
Only in 2.4.23pre6aa1: 71_xfs-aa-5
Only in 2.4.23pre6aa1: 71_xfs-mmap-1
Only in 2.4.22aa1: 71_xfs-tuning-1XFS 13pre-final merged.
Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
To really be able to help and not just waste some seek and cpu,
wait_on_buffershould honour theBH_Sync, but this is late in 2.4, and so I prefer to get rid of it instead of giving it the full power it should have.Only in 2.4.23pre6aa1: 9999900_soft-float-1
Trap any usage of the FPU in kernel (needed to trap things like
schedule_timeout(HZ*0.1)).Only in 2.4.22aa1: 9999901_aio-network-poll-pipe-1 Only in 2.4.23pre6aa1: 9999901_aio-poll-2
Leave only the aio-poll functionality because the network aio is still unfinished and nobody needs the pipe one (AFIK).
Only in 2.4.23pre6aa1: 9999_00_x86_64-suse-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-sys-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-tsc-c0-bandaid-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-warning-1 Only in 2.4.23pre6aa1: 9999_00_x86_64-zone-startpfn-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-bigpages-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-export-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-bitops-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-discontig-pmd-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-epoll-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-fault32-wrap-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-kgdb-1 Only in 2.4.23pre6aa1: 9999_01_x86_64-lvm32-no-checks-1
Merge x86-64 updates from Andi Kleen.
Only in 2.4.23pre6aa1: 9999_athlon-errata-prefetch-1
Fix athlon prefetch invalid faults from userspace. From Andi Kleen.
Only in 2.4.23pre6aa1: 9999_z-execve-race-1
Fix race in
exit_mmap.Only in 2.4.23pre6aa1: 9999_z-laptopmode-1
Allow the first read hitting the disk to flush all the dirty buffers. From Jens Axboe.
Only in 2.4.22aa1: 9999900_desktop-4
Only in 2.4.23pre6aa1: 9999_zz-dynamic-timeslice-1 Only in 2.4.23pre6aa1: 9999_zzz-dynamic-hz-1HZ is now dynamic, you can boot with HZ=50 HZ=100 HZ=500 or HZ=1000. However only HZ=100 and HZ=1000 are supported. Anything different from HZ=100 can trigger device driver bugs (those would already trigger on ia64 and alpha but on x86 the amount of drivers in use is larger).
But wait, you shouldn't use HZ=, you should only pass 'desktop' if you want to use the machine to behave as a better desktop and the kernel will just do the right thing.
max-timeslice/min-timeslice tunables are also provided as sysctl. Again no need to tune those, just pass 'desktop' if your machine is a desktop.
The scheduler has internal heuristics (the
avg_sleepfor example in the o1 scheduler) to try to identify the interactive tasks. Since those are heuristics there's also the chance of failing. By rescheduling taks at around 100hz even if the heuristic fails there's quite a good margin before your eye can see it. This should help with video players and games.Only in 2.4.23pre6aa1: 9999_zzzz-stackoverflow-1
Prevent overflows from happening on top of softirq. From Hugh Dickins.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Mathias Kretschmer
I'm getting the below errors compiling the bttv module.
Also, the commercial OSS sound driver fails to compile against it. It compiled under -pre6.
Otherwise, it seems to work fine for me.
Let me know, if you need any further info.
did you configure pre6 mainline with CONFIG_FW_LOADER = y ?
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Quoted 11 lines · Andrea Arcangeli
Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
This fixes a longstanding bug for a number of archs that haven't the dirty bit updated in hardware. For those archs we can't mark the pte writeable when it's still in swap cache, unless we don't mark it dirty too at the same time. Otherwise the cpu will go ahead writing to the page, no fault will happen and the swapcache will be still clean, and the data will be lost at the next zeroIO swapout leading to userspace data corruption and segfaults during swap. Affected archs are alpha/s390/s390x for example.
Quoted 7 lines
This bug was specific to the -aa VM, it couldn't happen in mainline. In my tree I optimized the code to exploited properties of archs that updates the bit in hardware for the first time. Hence the first need of a #define to differentiate the two code paths. The logic in the software-dirty-bit case will be less efficient of course (that's why there's a difference in the first place).
What does rmap do in this case then?
Quoted 20 lines · Mike Fedyk
Quoted 11 lines · Andrea Arcangeli
Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
This fixes a longstanding bug for a number of archs that haven't the dirty bit updated in hardware. For those archs we can't mark the pte writeable when it's still in swap cache, unless we don't mark it dirty too at the same time. Otherwise the cpu will go ahead writing to the page, no fault will happen and the swapcache will be still clean, and the data will be lost at the next zeroIO swapout leading to userspace data corruption and segfaults during swap. Affected archs are alpha/s390/s390x for example.
Quoted 7 lines
This bug was specific to the -aa VM, it couldn't happen in mainline. In my tree I optimized the code to exploited properties of archs that updates the bit in hardware for the first time. Hence the first need of a #define to differentiate the two code paths. The logic in the software-dirty-bit case will be less efficient of course (that's why there's a difference in the first place).
Quoted 1 line
What does rmap do in this case then?
no idea, but likely it wasn't affected. This was an ultra optimization I did, it was very aggressive and it broke the archs with the pte-dirty bit handled in software.
this is also the proof that the pte_* abstraction is not trasparent at all, and we definitely need a compile time #define to differentiate the two cases (I added it in the above patch for x86 and x86-64 and as said above this patch is infact an obvious noop for those two archs).
This is the code that broke it. the 'page' pointed by the pte is an exclusive page at that point, it means it's not shared by any other "mm" and it's of course an anonymous page. It can be in the swapcache or not, it doesn't make any difference (if it's not in the swapcache it's guaranteed to be marked PG_dirty at the phyiscal level).
if (write_access) pte = pte_mkdirty(pte); if (vma->vm_flags & VM_WRITE) pte = pte_mkwrite(pte);
This code is perfectly correct and it's more efficient than the software-dirty-bitflag because it avoids a copy-on-write page fault if this was a read access. If it was a read access we want to mark the pte writeable but not dirty, so if the page is still in the swapcache and nobody writes to it, we can swap out it zerocost. And at the same time we avoid any copy-on-write pagefault if somebody writes later to the page after we instantiated the mapping.
This is instead the version needed by archs with the dirty bit in software like ppc/s390/s390x/ppc64/alpha (there maybe more).
if (write_access) pte = pte_mkdirty(pte_mkwrite(pte));
On these archs we simply can't mark the pte writeable if we don't mark it dirty too, or somebody can write to the swappage and we would never notice, and the kernel would think it can swapout zerocost (swapcache still clean), while it really should do the I/O in that case.
The bug wasn't too bad, just a segfault or data corruption in userspace during heavy swapping. The kernel was stable, there's no way to crash the kernel forgetting a dirty bit. So it was also hardly noticeable. And if you had zero swap it simply couldn't trigger because no swapcache could be allocated. So the workaround swapoff -a is 100% reliable.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Re: 2.4.23pre6aa1: HZ not constant?
In reply to Andrea ArcangeliI am getting failures like this:
tr.c:81: initializer element is not constant
make[3]: *** [tr.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre-aa/net/802'
ecc.c:43: initializer element is not constant ecc.c:1495: warning: function declaration isn't a prototype make[2]: *** [ecc.o] Error 1
make[2]: Leaving directory `/data2/usr/local/src/linux-2.4-pre-aa/drivers/char'
where the problem is a file level definition like
static var = HZ;
and it seems that HZ is not anymore valid here (see include/linux/hz.h).
I have:
# CONFIG_DEBUG_KERNEL is not set
My gcc is 2.95 (Debian stable/woody).
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Re: 2.4.23pre6aa1: HZ not constant?
Quoted 14 lines · Eyal Lebedinsky
I am getting failures like this:
tr.c:81: initializer element is not constant
make[3]: *** [tr.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre-aa/net/802'ecc.c:43: initializer element is not constant ecc.c:1495: warning: function declaration isn't a prototype make[2]: *** [ecc.o] Error 1
make[2]: Leaving directory `/data2/usr/local/src/linux-2.4-pre-aa/drivers/char'
Quoted 4 lines
where the problem is a file level definition like
static var = HZ;and it seems that HZ is not anymore valid here (see
include/linux/hz.h).
HZ isn't known at compile time anymore, you pass it to the kernel as parameter dynamically.
the way to fix it is:
1) if the 'static var' variable is somehow visible to userspace then use USER_HZ and the user_to_kenrel_hz/user_to_kernel_hz_overflow (the latter is more efficient, it introduces zero branches , but it gives wrong results for very big inputs, it's ideal for sysctl set to things like 5*USER_HZ or anyways smaller than 2G/HZ ~= 1million).
2) if the static var is not visible to userspace (either via sysctl or module parameter) then we can just initialize it dynamically
This is the relevant fix for the above two problems. Please try again and let me know if something else doesn't compile. Thanks!
drivers/char/ecc.c renamed from drivers/char/ecc.c.~1~ +6 -6
@@ -40,7 +40,7 @@#define max (a,b) ((a)>(b)?(a):(b))static int ecc_scrub =-1 ; -static int ecc_ticks =HZ ; +static int ecc_ticks =USER_HZ ;static spinlock_t ecc_lock =SPIN_LOCK_UNLOCKED ;static int proc_ram_valid =0 ;
@@ -1410,7 +1410,7 @@ static void check_ecc(unsigned long dummif (cs.clear_err) cs.clear_err (); - ecc_timer.expires = jiffies + ecc_ticks; + ecc_timer.expires = jiffies +user_to_kernel_hz_overflow (ecc_ticks);add_timer (&ecc_timer);spin_unlock (&ecc_lock);
@@ -1616,8 +1616,8 @@ static int __init ecc_init(void)spin_lock_bh (&ecc_lock);printk (KERN_INFO "ECC: monitor version %s\n" ,ECC_VER ); -if (ecc_ticks !=HZ ) -printk (KERN_INFO "ECC: interval=%d ticks\n" , ecc_ticks); +if (user_to_kernel_hz_overflow (ecc_ticks) !=HZ ) +printk (KERN_INFO "ECC: interval=%d ticks\n" ,user_to_kernel_hz_overflow (ecc_ticks));for (loop=0 ;loop<MAX_BANKS ;loop++) { bank[loop].endaddr =0 ;
@@ -1650,7 +1650,7 @@ static int __init ecc_init(void)init_timer (&ecc_timer); ecc_timer.function = check_ecc; - ecc_timer.expires = jiffies + ecc_ticks; + ecc_timer.expires = jiffies +user_to_kernel_hz_overflow (ecc_ticks);add_timer (&ecc_timer); ecc_timer_valid =1 ;
@@ -1688,7 +1688,7 @@ MODULE_LICENSE("GPL");MODULE_PARM (ecc_scrub,"i" );MODULE_PARM_DESC (ecc_scrub,"Force ECC scrubbing: 0=off 1=on" );MODULE_PARM (ecc_ticks,"i" ); -MODULE_PARM_DESC (ecc_ticks,"Timer interval (default HZ)" ); +MODULE_PARM_DESC (ecc_ticks,"Timer interval (default USER_HZ)" );module_init (ecc_init);module_exit (ecc_exit);
net/802/tr.c renamed from net/802/tr.c.~1~ +4 -3
@@ -69,7 +69,7 @@ struct rif_cache_s {static rif_cache rif_table[RIF_TABLE_SIZE ];static spinlock_t rif_lock =SPIN_LOCK_UNLOCKED ; -#define RIF_TIMEOUT 60*10*HZ +#define RIF_TIMEOUT 60*10*USER_HZ#define RIF_CHECK_INTERVAL 60*HZ/*
@@ -78,7 +78,8 @@ static spinlock_t rif_lock = SPIN_LOCK_Ustatic struct timer_list rif_timer; -int sysctl_tr_rif_timeout =RIF_TIMEOUT ; +int __sysctl_tr_rif_timeout =RIF_TIMEOUT ; +#define sysctl_tr_rif_timeout user_to_kernel_hz_overflow(__sysctl_tr_rif_timeout)/* * Put the headers on a token ring packet. Token ring source routing
@@ -545,7 +546,7 @@ static int rif_get_info(char *buffer,chastatic int __init rif_init (void ) { - rif_timer.expires =RIF_TIMEOUT ; + rif_timer.expires =user_to_kernel_hz_overflow (RIF_TIMEOUT ); rif_timer.data =0L ; rif_timer.function = rif_check_expire;init_timer (&rif_timer);
net/802/sysctl_net_802.c renamed from net/802/sysctl_net_802.c.~1~ +2 -2
@@ -19,9 +19,9 @@ ctl_table e802_table[] = { };#ifdef CONFIG_TR -extern int sysctl_tr_rif_timeout; +extern int __sysctl_tr_rif_timeout;ctl_table tr_table[] = { - {NET_TR_RIF_TIMEOUT ,"rif_timeout" , &sysctl_tr_rif_timeout,sizeof (int ), + {NET_TR_RIF_TIMEOUT ,"rif_timeout" , &__sysctl_tr_rif_timeout,sizeof (int ),0644 ,NULL , &proc_dointvec}, {0 } };
Side note: there is no way that dynamic-hz could destabilize the kernel (assuming you don't pass HZ != 100 at boot time which can trigger bugs that would trigger anyways already on alpha or ia64). Every failure will always happen at compile time (the worst one was HZ*0.1, but that's now trapped by the -msoft-float, idea from Andi). I designed it strictly that way, if you enable the CONFIG_DEBUG_HZ = y then even a reader of HZ before the kernel parsing at boot initializes it will be safe defaulted to USER_HZ and will only generate an harmless printk (this is useful to port it to other archs). However it's recommended to leave CONFIG_DEBUG_HZ = n since enabling it would decrease performance due the additional sanity checking. While dyanmic-hz with debugging disabled is definitely not measurable in any benchmark and it allows to run true desktop multimedia with a guarantee of timeslices that provides a rescheduling rate higher than 50hz, that is the only way to reliably fool our eyes. The scheduler heuristics still play an important role but any heuristic isn't infallible and we can't depend on it. A desktop isn't computing anyways, boosting the reschedule rate is perfectly acceptable and the right thing to do IMHO.
Once somebody will start shipping cpus with address space numbers in the tlb (no brainer and needed _huge_ hardware optimization), the slowdown will be even less.
BTW, there's a -aa NUMA specific bug that is crashing my x86-64 in half an hour (it's related to the paddr stuff needed for 32bit numa with PAE, this mean 32bit NUMA is also unused), so don't compile a numa kernel, select smp only. Next release should work fine with numa too.
Quoted 2 lines
I have:
#CONFIG_DEBUG_KERNELis not set
that's ok, it's not related to this.
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Re: 2.4.23pre6aa1: scsi/pcmcia qlogic does not build
In reply to Andrea Arcangeligcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre-aa/include -Wall -Wstrict-
prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-poi
nter -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -malign-functio
ns=4 -DMODULE -DMODVERSIONS -include /data2/usr/local/src/linux-2.4-pre-aa/inclu de/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=qlogicf
as -DPCMCIA -D__NO_VERSION__ -c -o qlogicfas.o ../qlogicfas.c ../qlogicfas.c: In function `qlogicfas_detect':../qlogicfas.c:650: warning: passing arg 1 of scsi_unregister_R2c5e5a25' from incompatible pointer type ld -m elf_i386 -r -o qlogic_cs.o qlogic_stub.o qlogicfas.o qlogicfas.o: In function init_module':qlogicfas.o(.text+0xe40): multiple definition of `init_module' qlogic_stub.o(.text+0x770): first defined here
ld: Warning: size of symbol `init_module' changed from 77 to 58 in qlogicfas.o
qlogicfas.o: In function `cleanup_module':qlogicfas.o(.text+0xe80): multiple definition of `cleanup_module' qlogic_stub.o(.text+0x7c0): first defined here
ld: Warning: size of symbol `cleanup_module' changed from 40 to 16 in qlogicfas.o
make[3]: *** [qlogic_cs.o] Error 1
make[3]: Leaving directory `/data2/usr/local/src/linux-2.4-pre-aa/drivers/scsi/pcmcia'
A broken build?
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Re: 2.4.23pre6aa1: scsi/pcmcia qlogic does not build
Quoted 29 lines · Eyal Lebedinsky
gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre-aa/include -Wall -Wstrict-
prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-poi
nter -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -malign-functio
ns=4 -DMODULE -DMODVERSIONS -include /data2/usr/local/src/linux-2.4-pre-aa/include/linux/modversions.h-nostdinc -iwithprefix include -DKBUILD_BASENAME=qlogicf
as -DPCMCIA -D__NO_VERSION__ -c -o qlogicfas.o../qlogicfas.c../qlogicfas.c: In function `qlogicfas_detect':../qlogicfas.c:650: warning: passing arg 1 ofscsi_unregister_R2c5e5a25' from incompatible pointer type ld -m elf_i386 -r -o qlogic_cs.o qlogic_stub.o qlogicfas.o qlogicfas.o: In functioninit_module':qlogicfas.o(.text+0xe40): multiple definition of `init_module'qlogic_stub.o(.text+0x770): first defined here
ld: Warning: size of symbol `init_module' changed from 77 to 58 in qlogicfas.o
qlogicfas.o: In function `cleanup_module':qlogicfas.o(.text+0xe80): multiple definition of `cleanup_module'qlogic_stub.o(.text+0x7c0): first defined here
ld: Warning: size of symbol `cleanup_module' changed from 40 to 16 in qlogicfas.o
make[3]: *** [qlogic_cs.o] Error 1
make[3]: Leaving directory `/data2/usr/local/src/linux-2.4-pre-aa/drivers/scsi/pcmcia'
Quoted 1 line
A broken build?
it's a real compilation bug (not a mistake of your toolchain). The init_module function is defined both in qlogic_stub.c and in qlogicfas.c that imports scsi_module.c. One of the two has to go away or it can't link due a name clash across two objects.
after a first look I'm unsure what's the right fix. I guess the init module of the _cs has to get priority over the scsi_module.c. so basically you could hack something to disable the include of scsi_module.c from the other file. This assumes the _cs init_module will eventually register the scsi device too from the pcmcia callback.
However this should be a generic problem not introduced by my changes. Is there any scsi or pcmcia person interested in fixing it?
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Hi Andrea,
Quoted 4 lines · Andrea Arcangeli
URL:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1.gz
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.23; fi
depmod: *** Unresolved symbols in /lib/modules/2.4.23/kernel/fs/xfs/xfs.o
depmod: qsort
Regards,
Norberto
Quoted 37 lines · Andrea Arcangeli
URL:
Only in 2.4.23pre6aa1: 00_e-nodev-1s/NODEV/ENODEV/ fixes from Vojtech.
Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
Add missing
smb_mb().Only in 2.4.23pre6aa1: 00_proc-readlink-1
Remeber to free tmp buffer (from spender)
Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
Don't take the bkl (the same paths runs w/o the bkl elsewhere), from Chris Mason.
Only in 2.4.23pre6aa1: 01_softirq-nowait-1
We must really keep executing softirqs or it may take a too long time before ksoftirqd gets some cpu time. For an embedded device you may want to remove this, on a server we need this still.
Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
Ignore errors on exiting lock cleanups. From Trond.
Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
To really be able to help and not just waste some seek and cpu,
wait_on_buffershould honour theBH_Sync, but this is late in 2.4, and so I prefer to get rid of it instead of giving it the full power it should have.
Quoted 3 lines
Only in 2.4.23pre6aa1: 9999_z-execve-race-1
Fix race in
exit_mmap.
Andrea,
What about trying to merge this in mainline ?
Will I have to look at them and merge them manually like I did with the VM changes ?
:/
Quoted 43 lines · Marcelo Tosatti
Quoted 39 lines · Andrea Arcangeli
URL:
Only in 2.4.23pre6aa1: 00_e-nodev-1s/NODEV/ENODEV/ fixes from Vojtech.
Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
Add missing
smb_mb().Only in 2.4.23pre6aa1: 00_proc-readlink-1
Remeber to free tmp buffer (from spender)
Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
Don't take the bkl (the same paths runs w/o the bkl elsewhere), from Chris Mason.
Only in 2.4.23pre6aa1: 01_softirq-nowait-1
We must really keep executing softirqs or it may take a too long time before ksoftirqd gets some cpu time. For an embedded device you may want to remove this, on a server we need this still.
Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
Ignore errors on exiting lock cleanups. From Trond.
Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
To really be able to help and not just waste some seek and cpu,
wait_on_buffershould honour theBH_Sync, but this is late in 2.4, and so I prefer to get rid of it instead of giving it the full power it should have.Only in 2.4.23pre6aa1: 9999_z-execve-race-1
Quoted 8 lines
Quoted 1 line
Fix race in
exit_mmap.Andrea,
What about trying to merge this in mainline ?
Will I have to look at them and merge them manually like I did with the VM changes ?
I recall I sent one of these to you privately already (though not all of them). the ones to merge are these:
00_e-nodev-1 00_get_request_wait-race-1 00_proc-readlink-1 00_sync-buffer-scale-1 30_19-nfs-kill-unlock-1 9999900_BH_Sync-remove-1 9999_z-execve-race-1
I benchmarked BH_Sync as a worthless logic, it increases cpu usage and slowdown I/O a little due suprious unplugs, basically it makes no sense until we change wait_on_buffer not to call run_task_queue if the BH is BH_Sync, but personally I prefer to nuke it than to go mangle wait_on_buffer, it wouldn't be a huge optimization anyways (and it's a noop without more than one spindle running).
as you know I tried to fix the execve race w/o removing the fast path, but the lazy tlb code didn't work correctly, I'm unsure exactly what went wrong with it. The above fix is obviously safe instead and it indeed works fine. I'll be busy today and early next week. If something doesn't apply cleanly let me know and I can fix it for you.
the checksum fix as well doesn't need to be merged since the bug was fixed on a 2.4.19 based kernel, but 2.4.20 already has an alternate fix, but I believe the fix Andi did is much better since it's zerocost for the common aligned case, we only must avoid generating an invalid page fault, reading garbage from the next page has always been safe, since the garbage will be discared by the asm. So I'm evaluating if to drop the fix in 2.4.20 and to retain only Andi's one for performance reason. It's obvious Andi's fix won't alter performance for the 99% of common cases so personally I prefer it.
thanks!
Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Quoted 3 lines · Andrea Arcangeli
Quoted 3 lines
Quoted 3 lines
Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
Add missing
smb_mb().
Ok I see you add smp_mb() in get_request_wait_wakeup()... Can you please explain me in more detail why this is required?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Only in 2.4.23pre6aa1: 00_proc-readlink-1
Remeber to free tmp buffer (from spender)
Merged.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
Don't take the bkl (the same paths runs w/o the bkl elsewhere), from Chris Mason.
I prefer not applying this one.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Only in 2.4.23pre6aa1: 01_softirq-nowait-1
We must really keep executing softirqs or it may take a too long time before ksoftirqd gets some cpu time. For an embedded device you may want to remove this, on a server we need this still.
Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
Ignore errors on exiting lock cleanups. From Trond.
Talked with Trond and he has other fixes pending... Should have them by the weekend.
Quoted 23 lines
Quoted 11 lines
Quoted 11 lines
Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
To really be able to help and not just waste some seek and cpu,
wait_on_buffershould honour theBH_Sync, but this is late in 2.4, and so I prefer to get rid of it instead of giving it the full power it should have.Only in 2.4.23pre6aa1: 9999_z-execve-race-1
Fix race in
exit_mmap.I recall I sent one of these to you privately already (though not all of them). the ones to merge are these:
00_e-nodev-1 00_get_request_wait-race-1 00_proc-readlink-1 00_sync-buffer-scale-1 30_19-nfs-kill-unlock-1 9999900_BH_Sync-remove-1 9999_z-execve-race-1
Quoted 6 lines
I benchmarked
BH_Syncas a worthless logic, it increases cpu usage and slowdown I/O a little due suprious unplugs, basically it makes no sense until we changewait_on_buffernot to callrun_task_queueif the BH isBH_Sync, but personally I prefer to nuke it than to go manglewait_on_buffer, it wouldn't be a huge optimization anyways (and it's a noop without more than one spindle running).
I want to look with more time into this one...
Quoted 5 lines
as you know I tried to fix the execve race w/o removing the fast path, but the lazy tlb code didn't work correctly, I'm unsure exactly what went wrong with it. The above fix is obviously safe instead and it indeed works fine. I'll be busy today and early next week. If something doesn't apply cleanly let me know and I can fix it for you.
Thats merged as well.
Apart from this there's a huge pile of fixes all over in -aa. It would be good if we had them merged in.