* 2.6.0-test9-mm3
@ 2003-11-13 7:30 Andrew Morton
2003-11-13 20:03 ` [PATCH] linux-2.6.0-test9-mm3_verbose-timesource-acpi-pm_A0 john stultz
` (4 more replies)
0 siblings, 5 replies; 52+ messages in thread
From: Andrew Morton @ 2003-11-13 7:30 UTC (permalink / raw)
To: linux-kernel, linux-mm
http://www.zip.com.au/~akpm/linux/patches/2.6.0-test9-mm3.gz
kernel.org is being slow. Will appear at:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/
- Various new fixes; generally uncritical ones.
- Significant changes to the AIO and direct-io code. This needs beating
on; hopefully we're now close to a solution to the fairly complex problems
in there.
- Several ext2 and ext3 allocator fixes. These need serious testing on big
SMP.
- Anyone who has patches in here which they think should go into 2.6.0,
please retest them in -mm3 and let me know, thanks.
linus.patch
Latest Linus tree
-as-badness-warning-fix.patch
-3c509-mca-fix.patch
-ext2-allocation-fix.patch
-ohci-locking-fix.patch
-disable-ide-tcq.patch
-via-quirk-fix.patch
-raid1-recovery-fix.patch
-journal_remove_journal_head-assertion-fix.patch
-x86_64-tss-limit-fix.patch
-keyboard-repeat-rate-setting-fix.patch
-aio-refcounting-fix.patch
Merged
-RD16-rest-B6.patch
Al said to drop this.
+cramfs-use-pagecache.patch
cramfs fixes
-ia32-MSI-support-tweaks.patch
Folded into ia32-MSI-support.patch
+ia32-MSI-support-x86_64-fixes.patch
x86_64 build fix
-ia32-efi-asm-warning-fix.patch
-ia32-efi-support-mem-equals-fix.patch
-CONFIG_ACPI_EFI-defaults-off.patch
-ia32-efi-support-warning-fixes.patch
-ia32-efi-support-tidy.patch
-ia32-efi-other-arch-fix.patch
-efi-constant-sizing-fix.patch
-ia32-efi-config-option.patch
-ia32-efi-config-option-tweaks.patch
-ia32-efi-config-help-update.patch
-ia64-CONFIG_EFI-update.patch
Folded into ia32-efi-support.patch
+ia64-ia32-missing-compat-syscalls.patch
+compat-layer-fixes.patch
32-bit compat layer fixes
+compat-ioctl-for-i2c.patch
compat layer for i2c (old version)
+loop-bio-handling-fix.patch
Loop driver fixlet
-gcc-Os-if-embedded-better-help.patch
Folded into gcc-Os-if-embedded.patch
+as-request-poisoning-fix.patch
+as-fix-all-known-bugs.patch
Anticipatory scheduler fixes.
+more-than-256-cpus.patch
cpumask fixes for huge SMP
+acpi-pm-timer.patch
+acpi-pm-timer-fixes.patch
Yet another timer source for ia32
+ZONE_SHIFT-from-NODES_SHIFT.patch
Memory zone arith fixup
+ext2_new_inode-fixes.patch
+ext2_new_inode-fixes-tweaks.patch
+remove-ext2_reverve_inode.patch
ext2 fixes
+memmove-speedup.patch
Make memmove() faster.
+percpu-counter-linkage-fix.patch
Fix the build for when ext2 and ext3 are modular
+ide-scsi-warnings.patch
Print warnings when someone tries to use ide-scsi for a cdrom
+pipe-readv-writev.patch
pipe readv() and writev() correctness fix and speedup
+ext3_new_inode-scan-fix.patch
ext3 inode allocator fix
+lockless-semop.patch
sysv semaphore SMP speedup
+percpu_counter-use-alloc_percpu.patch
Fix the percpu counters for huge SMP.
+i450nx-scanning-fix.patch
PCI bridge fix for i450nx chipset machines
+serio-pm-fix.patch
Fix psmouse PM resume
+find_busiest_queue-commentary.patch
CPU scheduler comments
+ext2-block-allocator-fixes.patch
More ext2 allocator fixes.
+SOUND_CMPCI-config-typo-fix.patch
Sound driver config fix
+atkbd-24-compatibility.patch
Make AT keyboard userspace interface compatible with 2.4's.
+init_h-needs-compiler_h.patch
+init_h-needs-compiler_h-fix.patch
Compile fix
+cpu_sibling_map-fix.patch
cpu_sibling_map is broken on summit.
+tulip-hash-fix.patch
Fix multicast hash generation for some tulips
+context-switch-accounting-fix.patch
Fix CPU scheduler beancounting with CONFIG_PREEMPT.
+access-vfs_permission-fix.patch
Fix access()
+eicon-linkage-fix.patch
ISDM build fix
+kobject-docco-additions.patch
Documentation additions.
-O_DIRECT-race-fixes-rework-XFS-fix.patch
-O_DIRECT-race-fixes-rework-XFS-fix-fix.patch
Folded into O_DIRECT-race-fixes-rollup.patch
+dio-aio-fixes.patch
+dio-aio-fixes-fixes.patch
AIO/direct-io fixes
+promise-sata-id.patch
Additional STAT PCI ID.
All 201 patches
linus.patch
mm.patch
add -mmN to EXTRAVERSION
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb-buff-too-big.patch
kgdb buffer overflow fix
kgdb-warning-fix.patch
kgdbL warning fix
kgdb-build-fix.patch
kgdb-spinlock-fix.patch
kgdb-fix-debug-info.patch
kgdb: CONFIG_DEBUG_INFO fix
kgdb-cpumask_t.patch
kgdb-x86_64-fixes.patch
x86_64 fixes
kgdb-over-ethernet.patch
kgdb-over-ethernet patch
kgdb-over-ethernet-fixes.patch
kgdb-over-ethernet fixlets
kgdb-CONFIG_NET_POLL_CONTROLLER.patch
kgdb: replace CONFIG_KGDB with CONFIG_NET_RX_POLL in net drivers
kgdb-handle-stopped-NICs.patch
kgdb: handle netif_stopped NICs
eepro100-poll-controller.patch
tlan-poll_controller.patch
tulip-poll_controller.patch
tg3-poll_controller.patch
kgdb: tg3 poll_controller
8139too-poll_controller.patch
8139too poll controller
kgdb-eth-smp-fix.patch
kgdb-over-ethernet: fix SMP
kgdb-eth-reattach.patch
kgdb-skb_reserve-fix.patch
kgdb-over-ethernet: skb_reserve() fix
must-fix.patch
should-fix.patch
must-fix-update-01.patch
must fix lists update
RD1-cdrom_ioctl-B6.patch
RD2-ioctl-B6.patch
RD2-ioctl-B6-fix.patch
RD2-ioctl-B6 fixes
RD3-cdrom_open-B6.patch
RD4-open-B6.patch
RD5-cdrom_release-B6.patch
RD6-release-B6.patch
RD7-presto_journal_close-B6.patch
RD8-f_mapping-B6.patch
RD9-f_mapping2-B6.patch
RD10-i_sem-B6.patch
RD11-f_mapping3-B6.patch
RD12-generic_osync_inode-B6.patch
RD13-bd_acquire-B6.patch
RD14-generic_write_checks-B6.patch
RD15-I_BDEV-B6.patch
cramfs-use-pagecache.patch
cramfs: use pagecache better
invalidate_inodes-speedup.patch
invalidate_inodes speedup
invalidate_inodes-speedup-fixes-2.patch
more invalidate_inodes speedup fixes
serio-01-renaming.patch
serio: rename serio_[un]register_slave_port to __serio_[un]register_port
serio-02-race-fix.patch
serio: possible race between port removal and kseriod
serio-03-blacklist.patch
Add black list to handler<->device matching
serio-04-synaptics-cleanup.patch
Synaptics: code cleanup
serio-05-reconnect-facility.patch
serio: reconnect facility
serio-06-synaptics-use-reconnect.patch
Synaptics: use serio_reconnect
acpi_off-fix.patch
fix acpi=off
cfq-4.patch
CFQ io scheduler
CFQ fixes
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-bar-0-fix.patch
Allow PCI BARs that start at 0
ppc64-reloc_hide.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
input-use-after-free-checks.patch
input layer debug checks
aic7xxx-parallel-build-fix.patch
fix parallel builds for aic7xxx
ramdisk-cleanup.patch
intel8x0-cleanup.patch
intel8x0 cleanups
pdflush-diag.patch
kobject-oops-fixes.patch
fix oopses is kobject parent is removed before child
futex-uninlinings.patch
futex uninlining
zap_page_range-debug.patch
zap_page_range() debug
call_usermodehelper-retval-fix-3.patch
Make call_usermodehelper report exit status
asus-L5-fix.patch
Asus L5 framebuffer fix
jffs-use-daemonize.patch
tulip-NAPI-support.patch
tulip NAPI support
tulip-napi-disable.patch
tulip NAPI: disable poll in close
get_user_pages-handle-VM_IO.patch
ia32-MSI-support.patch
Updated ia32 MSI Patches
ia32-MSI-support-x86_64-fixes.patch
ia32-efi-support.patch
EFI support for ia32
efi warning fix
fix EFI for ppc64, ia64
efi: warning fixes
ia32 EFI: Add CONFIG_EFI
efi: Update Kconfig help
efi update patch (ia64)
support-zillions-of-scsi-disks.patch
support many SCSI disks
SGI-IOC4-IDE-chipset-support.patch
Add support for SGI's IOC4 chipset
sparc32-sched_clock.patch
pcibios_test_irq-fix.patch
Fix pcibios test IRQ handler return
fixmap-in-proc-pid-maps.patch
report user-readable fixmap area in /proc/PID/maps
i82365-sysfs-ordering-fix.patch
Fix init_i82365 sysfs ordering oops
pci_set_power_state-might-sleep.patch
ia64-ia32-missing-compat-syscalls.patch
From: Arun Sharma <arun.sharma@intel.com>
Subject: Missing compat syscalls in ia64
compat-layer-fixes.patch
Minor bug fixes to the compat layer
compat-ioctl-for-i2c.patch
compat_ioctl for i2c
compat_ioctl-cleanup.patch
cleanup of compat_ioctl functions
fix-sqrt.patch
sqrt() fixes
scale-min_free_kbytes.patch
scale the initial value of min_free_kbytes
cdrom-allocation-try-harder.patch
Use __GFP_REPEAT for cdrom buffer
sym-2.1.18f.patch
CONFIG_STANDALONE-default-to-n.patch
Make CONFIG_STANDALONE default to N
extra-buffer-diags.patch
nosysfs.patch
constant_test_bit-doesnt-like-zwanes-gcc.patch
gcc bug workaround for constant_test_bit()
slab-leak-detector.patch
slab leak detector
early-serial-registration-fix.patch
serial console registration bugfix
3c527-smp-update.patch
SMP support on 3c527 net driver
3c527-race-fix.patch
ext3-latency-fix.patch
ext3 scheduling latency fix
videobuf_waiton-race-fix.patch
firmware-kernel_thread-on-demand.patch
Remove workqueue usage from request_firmware_async()
loop-autoloading-fix.patch
Fix loop module auto loading
loop-module-alias.patch
loop needs MODULE_ALIAS_BLOCK
loop-remove-blkdev-special-case.patch
loop-highmem.patch
remove useless highmem bounce from loop/cryptoloop
loop-highmem-fixes.patch
loop-bio-handling-fix.patch
loop: BIO handling fix
cmpci-set_fs-fix.patch
cmpci.c: remove pointless set_fs()
dentry-bloat-fix-2.patch
Fix dcache and icache bloat with deep directories
nls-config-fixes.patch
NSL config fixes
proc_pid_lookup-vs-exit-race-fix.patch
Fix proc_pid_lookup vs exit race
gcc-Os-if-embedded.patch
Add `gcc -Os' config option
aic7xxx-sleep-in-spinlock-fix.patch
vm86-sysenter-fix.patch
Fix sysenter disabling in vm86 mode
gettimeofday-resolution-fix.patch
gettimeofday resolution fix
refill_counter-overflow-fix.patch
vmscan: reset refill_counter after refilling the inactive list
verbose-timesource.patch
be verbose about the time source
as-regression-fix.patch
Fix IO scheduler regression
as-request-poisoning.patch
AS: request poisoning
as-request-poisoning-fix.patch
AS: request poisining fix
as-fix-all-known-bugs.patch
AS fixes
as-new-process-estimation.patch
AS: new process estimation
as-cooperative-thinktime.patch
AS: thinktime improvement
scale-nr_requests.patch
scale nr_requests with TCQ depth
truncate_inode_pages-check.patch
local_bh_enable-warning-fix.patch
cdc-acm-softirq-rx.patch
cdc-acm: move rx processing to softirq
forcedeth.patch
forcedeth: nForce ethernet driver
reiserfs-pinned-buffer-fix.patch
reiserfs pinned buffer fix
proc-pid-maps-output-fix.patch
Restore /proc/pid/maps formatting
atomic_dec-debug.patch
atomic_dec debug
sis900-pm-support.patch
Add PM support to sis900 network driver
8139too-locking-fix.patch
8139too locking fix
ia32-wp-test-cleanup.patch
ia32 WP test cleanup
hugetlb-needs-pse.patch
ia32: hugetlb needs pse
powermate-payload-size-fix.patch
Griffin Powermate fix
more-than-256-cpus.patch
Fix for more than 256 CPUs
acpi-pm-timer.patch
ACPI PM Timer
acpi-pm-timer-fixes.patch
ACPI PM-Timer fixes
ZONE_SHIFT-from-NODES_SHIFT.patch
Use NODES_SHIFT to calculate ZONE_SHIFT
ext2_new_inode-fixes.patch
Fix bugs in ext2_new_inode()
ext2_new_inode-fixes-tweaks.patch
ext2_new_inode: more tweaking
remove-ext2_reverve_inode.patch
memmove-speedup.patch
optimize ia32 memmove
percpu-counter-linkage-fix.patch
fix percpu_counter_mod linkage problem
ide-scsi-warnings.patch
ide-scsi: warn when used for cdroms
pipe-readv-writev.patch
Fix writev atomicity on pipe/fifo
ext3_new_inode-scan-fix.patch
ext3_new_inode fixlet
lockless-semop.patch
lockless semop
percpu_counter-use-alloc_percpu.patch
use alloc_percpu in percpu_counters
i450nx-scanning-fix.patch
i450nx PCI scanning fix
serio-pm-fix.patch
psmouse pm resume fix
find_busiest_queue-commentary.patch
find_busiest_queue() commentary fix
ext2-block-allocator-fixes.patch
ext2 block allocator fixes
SOUND_CMPCI-config-typo-fix.patch
fix SOUND_CMPCI Configure help entry
atkbd-24-compatibility.patch
Fixes for keyboard 2.4 compatibility
init_h-needs-compiler_h.patch
init.h needs to include compiler.h
init_h-needs-compiler_h-fix.patch
compile fix for older gcc's
cpu_sibling_map-fix.patch
cpu_sibling_map fix
tulip-hash-fix.patch
tulip filter hash fix
context-switch-accounting-fix.patch
Fix context switch accounting
access-vfs_permission-fix.patch
Subject: Re: [PATCH] fix access() / vfs_permission() bug
eicon-linkage-fix.patch
eicon/ and hardware/eicon/ drivers using the same symbols
kobject-docco-additions.patch
Improve documentation for kobjects
list_del-debug.patch
list_del debug check
print-build-options-on-oops.patch
show_task-free-stack-fix.patch
show_task() fix and cleanup
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
printk-oops-mangle-fix.patch
disentangle printk's whilst oopsing on SMP
4g-2.6.0-test2-mm2-A5.patch
4G/4G split patch
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
use direct_copy_{to,from}_user for kernel access in mm/usercopy.c
4G/4G might_sleep warning fix
4g/4g pagetable accounting fix
4g4g-athlon-prefetch-handling-fix.patch
4g4g-wp-test-fix.patch
Fix 4G/4G and WP test lockup
4g4g-KERNEL_DS-usercopy-fix.patch
4G/4G KERNEL_DS usercopy again
ppc-fixes.patch
make mm4 compile on ppc
aic7xxx_old-oops-fix.patch
O_DIRECT-race-fixes-rollup.patch
DIO fixes forward port and AIO-DIO fix
O_DIRECT race fixes comments
O_DRIECT race fixes fix fix fix
DIO locking rework
O_DIRECT XFS fix
dio-aio-fixes.patch
direct-io AIO fixes
dio-aio-fixes-fixes.patch
dio-aio fix fix
readahead-multiple-fixes.patch
readahead: multipole performance fixes
readahead-simplification.patch
readahead simplification
aio-sysctl-parms.patch
aio sysctl parms
aio-01-retry.patch
AIO: Core retry infrastructure
Fix aio process hang on EINVAL
AIO: flush workqueues before destroying ioctx'es
AIO: hold the context lock across unuse_mm
task task_lock in use_mm()
4g4g-aio-hang-fix.patch
Fix AIO and 4G-4G hang
aio-retry-elevated-refcount.patch
aio: extra ref count during retry
aio-splice-runlist.patch
Splice AIO runlist for fairer handling of multiple io contexts
aio-02-lockpage_wq.patch
AIO: Async page wait
aio-03-fs_read.patch
AIO: Filesystem aio read
aio-04-buffer_wq.patch
AIO: Async buffer wait
lock_buffer_wq fix
aio-05-fs_write.patch
AIO: Filesystem aio write
aio-06-bread_wq.patch
AIO: Async block read
aio-07-ext2getblk_wq.patch
AIO: Async get block for ext2
O_SYNC-speedup-2.patch
speed up O_SYNC writes
O_SYNC-speedup-2-f_mapping-fixes.patch
aio-09-o_sync.patch
aio O_SYNC
AIO: fix a BUG
Unify o_sync changes for aio and regular writes
aio-O_SYNC-fix bits got lost
aio: writev nr_segs fix
More AIO O_SYNC related fixes
aio-09-o_sync-f_mapping-fixes.patch
gang_lookup_next.patch
Change the page gang lookup API
aio-gang_lookup-fix.patch
AIO gang lookup fixes
aio-O_SYNC-short-write-fix.patch
Fix for O_SYNC short writes
aio-12-readahead.patch
AIO: readahead fixes
aio O_DIRECT no readahead
Unified page range readahead for aio and regular reads
aio-12-readahead-f_mapping-fix.patch
aio-readahead-speedup.patch
Readahead issues and AIO read speedup
promise-sata-id.patch
add Promise 20376 PCI ID
^ permalink raw reply [flat|nested] 52+ messages in thread* [PATCH] linux-2.6.0-test9-mm3_verbose-timesource-acpi-pm_A0 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton @ 2003-11-13 20:03 ` john stultz 2003-11-13 22:03 ` 2.6.0-test9-mm3 - AIO test results Daniel McNeil ` (3 subsequent siblings) 4 siblings, 0 replies; 52+ messages in thread From: john stultz @ 2003-11-13 20:03 UTC (permalink / raw) To: Andrew Morton; +Cc: lkml, linux-mm On Wed, 2003-11-12 at 23:30, Andrew Morton wrote: > +acpi-pm-timer.patch > +acpi-pm-timer-fixes.patch > > Yet another timer source for ia32 > [snip] > verbose-timesource.patch > be verbose about the time source Andrew, I forgot that I sent you the verbose-timesource patch. The ACPI PM time source will need this simple fix to work along side that patch. thanks -john ===== arch/i386/kernel/timers/timer_pm.c 1.6 vs edited ===== --- 1.6/arch/i386/kernel/timers/timer_pm.c Tue Nov 4 11:39:50 2003 +++ edited/arch/i386/kernel/timers/timer_pm.c Thu Nov 13 11:12:23 2003 @@ -185,6 +185,7 @@ /* acpi timer_opts struct */ struct timer_opts timer_pmtmr = { + .name = "pmtmr", .init = init_pmtmr, .mark_offset = mark_offset_pmtmr, .get_offset = get_offset_pmtmr, ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton 2003-11-13 20:03 ` [PATCH] linux-2.6.0-test9-mm3_verbose-timesource-acpi-pm_A0 john stultz @ 2003-11-13 22:03 ` Daniel McNeil 2003-11-17 5:25 ` Suparna Bhattacharya 2003-11-13 22:04 ` 2.6.0-test9-mm3 (compile stats) John Cherry ` (2 subsequent siblings) 4 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-11-13 22:03 UTC (permalink / raw) To: Andrew Morton; +Cc: Linux Kernel Mailing List, linux-mm, linux-aio Andrew, I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. I tested using the test programs aiocp and aiodio_sparse. (see http://developer.osdl.org/daniel/AIO/) Using aiocp with i/o sizes from 1k to 512k to copy files worked without any errors or kernel debug messages. With 64k i/o, the aiodio_sparse program complete without any errors. There are no kernel error messages, so that is good. There are still problems with non power of 2 i/o sizes using AIO and O_DIRECT. It hangs with aio's that do not seem to complete. The test does exit when hitting ^c and there are no kernel messages. Test output below: $ ./aiodio_sparse $ ./aiodio_sparse -dd -s 1751k -r 18k -w 11k child 1843, read loop count 0 io_submit() return 16 aiodio_sparse: 16 i/o in flight aiodio_sparse: offset 180224 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 191488 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 202752 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 214016 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 225280 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 236544 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 247808 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 259072 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 270336 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 281600 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 292864 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 304128 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 child 1843, read loop count 10 io_submit() return 1 aiodio_sparse: offset 315392 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 326656 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 337920 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 349184 filesize 1793024 inflight 16 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 11264 res2 0 io_submit() return 1 aiodio_sparse: offset 360448 filesize 1793024 inflight 16 child 1843, read loop count 20 child 1843, read loop count 30 child 1843, read loop count 40 child 1843, read loop count 50 child 1843, read loop count 60 child 1843, read loop count 70 $ ./aiodio_sparse -i 9 -d -s 180k -r 18k -w 18k io_submit() return 9 aiodio_sparse: 9 i/o in flight aiodio_sparse: offset 165888 filesize 184320 inflight 9 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 18432 res2 0 io_submit() return 1 child 2060, read loop count 0 child 2060, read loop count 10 child 2060, read loop count 20 Daniel On Wed, 2003-11-12 at 23:30, Andrew Morton wrote: > - Significant changes to the AIO and direct-io code. This needs beating > on; hopefully we're now close to a solution to the fairly complex problems > in there. > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-13 22:03 ` 2.6.0-test9-mm3 - AIO test results Daniel McNeil @ 2003-11-17 5:25 ` Suparna Bhattacharya 2003-11-18 1:15 ` Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Suparna Bhattacharya @ 2003-11-17 5:25 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio On Thu, Nov 13, 2003 at 02:03:58PM -0800, Daniel McNeil wrote: > Andrew, > > I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. > I tested using the test programs aiocp and aiodio_sparse. > (see http://developer.osdl.org/daniel/AIO/) > > Using aiocp with i/o sizes from 1k to 512k to copy files worked > without any errors or kernel debug messages. > > With 64k i/o, the aiodio_sparse program complete without any errors. > There are no kernel error messages, so that is good. > > There are still problems with non power of 2 i/o sizes using AIO and > O_DIRECT. It hangs with aio's that do not seem to complete. The test > does exit when hitting ^c and there are no kernel messages. Test output > below: Could you check if the following patch fixes the problem for you ? Regards Suparna -------------------------------------------------------------- With this patch, when the DIO code falls back to buffered i/o after having submitted part of the i/o, then buffered i/o is issued only for the remaining part of the request (i.e. the part not already covered by DIO). diff -ur pure-mm3/fs/direct-io.c linux-2.6.0-test9-mm3/fs/direct-io.c --- pure-mm3/fs/direct-io.c 2003-11-14 09:09:06.000000000 +0530 +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-17 09:00:47.000000000 +0530 @@ -74,6 +74,7 @@ been performed at the start of a write */ int pages_in_io; /* approximate total IO pages */ + size_t size; /* total request size (doesn't change)*/ sector_t block_in_file; /* Current offset into the underlying file in dio_block units. */ unsigned blocks_available; /* At block_in_file. changes */ @@ -226,7 +227,7 @@ dio_complete(dio, dio->block_in_file << dio->blkbits, dio->result); /* Complete AIO later if falling back to buffered i/o */ - if (dio->result != -ENOTBLK) { + if (dio->result >= dio->size || dio->rw == READ) { aio_complete(dio->iocb, dio->result, 0); kfree(dio); } else { @@ -889,6 +890,7 @@ dio->blkbits = blkbits; dio->blkfactor = inode->i_blkbits - blkbits; dio->start_zero_done = 0; + dio->size = 0; dio->block_in_file = offset >> blkbits; dio->blocks_available = 0; dio->cur_page = NULL; @@ -925,7 +927,7 @@ for (seg = 0; seg < nr_segs; seg++) { user_addr = (unsigned long)iov[seg].iov_base; - bytes = iov[seg].iov_len; + dio->size += bytes = iov[seg].iov_len; /* Index into the first page of the first block */ dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; @@ -956,6 +958,13 @@ } } /* end iovec loop */ + if (ret == -ENOTBLK && rw == WRITE) { + /* + * The remaining part of the request will be + * be handled by buffered I/O when we return + */ + ret = 0; + } /* * There may be some unwritten disk at the end of a part-written * fs-block-sized block. Go zero that now. @@ -986,19 +995,13 @@ */ if (dio->is_async) { if (ret == 0) - ret = dio->result; /* Bytes written */ - if (ret == -ENOTBLK) { - /* - * The request will be reissued via buffered I/O - * when we return; Any I/O already issued - * effectively becomes redundant. - */ - dio->result = ret; + ret = dio->result; + if (ret > 0 && dio->result < dio->size && rw == WRITE) { dio->waiter = current; } finished_one_bio(dio); /* This can free the dio */ blk_run_queues(); - if (ret == -ENOTBLK) { + if (dio->waiter) { /* * Wait for already issued I/O to drain out and * release its references to user-space pages @@ -1032,7 +1035,8 @@ } dio_complete(dio, offset, ret); /* We could have also come here on an AIO file extend */ - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && + dio->result < dio->size)) aio_complete(iocb, ret, 0); kfree(dio); } diff -ur pure-mm3/mm/filemap.c linux-2.6.0-test9-mm3/mm/filemap.c --- pure-mm3/mm/filemap.c 2003-11-14 09:15:08.000000000 +0530 +++ linux-2.6.0-test9-mm3/mm/filemap.c 2003-11-15 11:11:16.000000000 +0530 @@ -1895,14 +1895,16 @@ */ if (written >= 0 && file->f_flags & O_SYNC) status = generic_osync_inode(inode, mapping, OSYNC_METADATA); - if (written >= 0 && !is_sync_kiocb(iocb)) + if (written >= count && !is_sync_kiocb(iocb)) written = -EIOCBQUEUED; - if (written != -ENOTBLK) + if (written < 0 || written >= count) goto out_status; /* * direct-io write to a hole: fall through to buffered I/O + * for completing the rest of the request. */ - written = 0; + pos += written; + count -= written; } buf = iov->iov_base; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-17 5:25 ` Suparna Bhattacharya @ 2003-11-18 1:15 ` Daniel McNeil 2003-11-18 1:37 ` Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-11-18 1:15 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Suparna, Good news and bad news. Your patch does fix the non-power of two i/o size problems where AIO previously did not complete: $ ./aiodio_sparse -s 1751k -r 18k -w 11k $ aiodio_sparse -i 9 -dd -s 180k -r 18k -w 18k io_submit() return 9 aiodio_sparse: 9 i/o in flight aiodio_sparse: offset 165888 filesize 184320 inflight 9 aiodio_sparse: io_getevent() returned 1 aiodio_sparse: io_getevent() res 18432 res2 0 io_submit() return 1 AIO DIO write done unlinking file dio_sparse done writing, kill children aiodio_sparse 0 children had errors But when testing using aiocp using O_DIRECT to copy a file to an already allocated file, the aiocp process hangs. I used i/o size of 4k and that compeleted. Using i/o size of 1k and 2k, the aiocp process hung during io_sumbit() and are unkillable. Here are the stack traces: # ps -fu daniel | grep aiocp daniel 1920 1 0 16:45 ? 00:00:07 aiocp -b 1k -n 1 -f DIRECT glibc-2.3.2.tar ff2 daniel 2083 2037 0 17:00 pts/2 00:00:03 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 aiocp D 00000001 1920 1 1902 (NOTLB) e70abd04 00200086 c18dbc80 00000001 00000003 c02897fc 00000060 00200246 f7cdb8b4 c16522f0 c18dbc80 0000309c 640a05eb 0000008b e6d9e660 c0289a16 f7cdb8b4 e87e95cc c18dbc80 00000000 00000001 e70abd10 c0123712 e70aa000 Call Trace: [<c02897fc>] generic_unplug_device+0x50/0xbd [<c0289a16>] blk_run_queues+0xa9/0x15c [<c0123712>] io_schedule+0x26/0x30 [<c0192242>] direct_io_worker+0x376/0x5ab [<c014840f>] generic_file_direct_IO+0x70/0x89 [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c014840f>] generic_file_direct_IO+0x70/0x89 [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff [<c0121b70>] schedule+0x3ac/0x7ef [<c0145f48>] generic_file_aio_read+0x33/0x37 [<c0194ad3>] aio_pread+0x34/0x5f [<c0193bec>] aio_run_iocb+0xa6/0x1ed [<c019316f>] __aio_get_req+0x27/0x158 [<c0194a9f>] aio_pread+0x0/0x5f [<c0194f62>] io_submit_one+0x1ea/0x2b7 [<c0195110>] sys_io_submit+0xe1/0x194 [<c03c29a7>] syscall_call+0x7/0xb [<c03c007b>] rpc_depopulate+0x1aa/0x24b aiocp D 366EDC94 2083 2037 (NOTLB) e758bd04 00200082 f71ba000 366edc94 00000161 c02897fc 00000060 366edc94 00000161 f71ba000 c18d3c80 000069a9 366f5a0e 00000161 e8d4acc0 c0289a16 f7cdb8b4 e960465c c18d3c80 00000000 00000001 e758bd10 c0123712 e758a000 Call Trace: [<c02897fc>] generic_unplug_device+0x50/0xbd [<c0289a16>] blk_run_queues+0xa9/0x15c [<c0123712>] io_schedule+0x26/0x30 [<c0192242>] direct_io_worker+0x376/0x5ab [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c014840f>] generic_file_direct_IO+0x70/0x89 [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff [<c0259d3e>] write_chan+0x165/0x21e [<c0145f48>] generic_file_aio_read+0x33/0x37 [<c0194ad3>] aio_pread+0x34/0x5f [<c0193bec>] aio_run_iocb+0xa6/0x1ed [<c019316f>] __aio_get_req+0x27/0x158 [<c0194a9f>] aio_pread+0x0/0x5f [<c02532ab>] tty_write+0x1e8/0x3b2 [<c0194f62>] io_submit_one+0x1ea/0x2b7 [<c0195110>] sys_io_submit+0xe1/0x194 [<c03c29a7>] syscall_call+0x7/0xb [<c03c007b>] rpc_depopulate+0x1aa/0x24b Daniel On Sun, 2003-11-16 at 21:25, Suparna Bhattacharya wrote: > On Thu, Nov 13, 2003 at 02:03:58PM -0800, Daniel McNeil wrote: > > Andrew, > > > > I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. > > I tested using the test programs aiocp and aiodio_sparse. > > (see http://developer.osdl.org/daniel/AIO/) > > > > Using aiocp with i/o sizes from 1k to 512k to copy files worked > > without any errors or kernel debug messages. > > > > With 64k i/o, the aiodio_sparse program complete without any errors. > > There are no kernel error messages, so that is good. > > > > There are still problems with non power of 2 i/o sizes using AIO and > > O_DIRECT. It hangs with aio's that do not seem to complete. The test > > does exit when hitting ^c and there are no kernel messages. Test output > > below: > > Could you check if the following patch fixes the problem for you ? > > Regards > Suparna > > -------------------------------------------------------------- > > With this patch, when the DIO code falls back to buffered i/o after > having submitted part of the i/o, then buffered i/o is issued only > for the remaining part of the request (i.e. the part not already > covered by DIO). > > diff -ur pure-mm3/fs/direct-io.c linux-2.6.0-test9-mm3/fs/direct-io.c > --- pure-mm3/fs/direct-io.c 2003-11-14 09:09:06.000000000 +0530 > +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-17 09:00:47.000000000 +0530 > @@ -74,6 +74,7 @@ > been performed at the start of a > write */ > int pages_in_io; /* approximate total IO pages */ > + size_t size; /* total request size (doesn't change)*/ > sector_t block_in_file; /* Current offset into the underlying > file in dio_block units. */ > unsigned blocks_available; /* At block_in_file. changes */ > @@ -226,7 +227,7 @@ > dio_complete(dio, dio->block_in_file << dio->blkbits, > dio->result); > /* Complete AIO later if falling back to buffered i/o */ > - if (dio->result != -ENOTBLK) { > + if (dio->result >= dio->size || dio->rw == READ) { > aio_complete(dio->iocb, dio->result, 0); > kfree(dio); > } else { > @@ -889,6 +890,7 @@ > dio->blkbits = blkbits; > dio->blkfactor = inode->i_blkbits - blkbits; > dio->start_zero_done = 0; > + dio->size = 0; > dio->block_in_file = offset >> blkbits; > dio->blocks_available = 0; > dio->cur_page = NULL; > @@ -925,7 +927,7 @@ > > for (seg = 0; seg < nr_segs; seg++) { > user_addr = (unsigned long)iov[seg].iov_base; > - bytes = iov[seg].iov_len; > + dio->size += bytes = iov[seg].iov_len; > > /* Index into the first page of the first block */ > dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; > @@ -956,6 +958,13 @@ > } > } /* end iovec loop */ > > + if (ret == -ENOTBLK && rw == WRITE) { > + /* > + * The remaining part of the request will be > + * be handled by buffered I/O when we return > + */ > + ret = 0; > + } > /* > * There may be some unwritten disk at the end of a part-written > * fs-block-sized block. Go zero that now. > @@ -986,19 +995,13 @@ > */ > if (dio->is_async) { > if (ret == 0) > - ret = dio->result; /* Bytes written */ > - if (ret == -ENOTBLK) { > - /* > - * The request will be reissued via buffered I/O > - * when we return; Any I/O already issued > - * effectively becomes redundant. > - */ > - dio->result = ret; > + ret = dio->result; > + if (ret > 0 && dio->result < dio->size && rw == WRITE) { > dio->waiter = current; > } > finished_one_bio(dio); /* This can free the dio */ > blk_run_queues(); > - if (ret == -ENOTBLK) { > + if (dio->waiter) { > /* > * Wait for already issued I/O to drain out and > * release its references to user-space pages > @@ -1032,7 +1035,8 @@ > } > dio_complete(dio, offset, ret); > /* We could have also come here on an AIO file extend */ > - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) > + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && > + dio->result < dio->size)) > aio_complete(iocb, ret, 0); > kfree(dio); > } > diff -ur pure-mm3/mm/filemap.c linux-2.6.0-test9-mm3/mm/filemap.c > --- pure-mm3/mm/filemap.c 2003-11-14 09:15:08.000000000 +0530 > +++ linux-2.6.0-test9-mm3/mm/filemap.c 2003-11-15 11:11:16.000000000 +0530 > @@ -1895,14 +1895,16 @@ > */ > if (written >= 0 && file->f_flags & O_SYNC) > status = generic_osync_inode(inode, mapping, OSYNC_METADATA); > - if (written >= 0 && !is_sync_kiocb(iocb)) > + if (written >= count && !is_sync_kiocb(iocb)) > written = -EIOCBQUEUED; > - if (written != -ENOTBLK) > + if (written < 0 || written >= count) > goto out_status; > /* > * direct-io write to a hole: fall through to buffered I/O > + * for completing the rest of the request. > */ > - written = 0; > + pos += written; > + count -= written; > } > > buf = iov->iov_base; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-18 1:15 ` Daniel McNeil @ 2003-11-18 1:37 ` Daniel McNeil 2003-11-18 11:55 ` Suparna Bhattacharya 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-11-18 1:37 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Obviously, the ps output in my previous email showed that the hangs were with 1k i/o sizes. More testing using 2k, 4k, 16k, 32k, 64k, 128k, 256k and 512k all completed correctly. Even 11k and 17k worked. $ ls -l -rw------- 1 daniel daniel 88289280 Jun 9 16:54 glibc-2.3.2.tar -rw-rw-r-- 1 daniel daniel 88289280 Nov 17 17:32 ff2 So, only 1k is hanging so far. Daniel On Mon, 2003-11-17 at 17:15, Daniel McNeil wrote: > Suparna, > > Good news and bad news. Your patch does fix the non-power of two i/o > size problems where AIO previously did not complete: > > $ ./aiodio_sparse -s 1751k -r 18k -w 11k > $ aiodio_sparse -i 9 -dd -s 180k -r 18k -w 18k > io_submit() return 9 > aiodio_sparse: 9 i/o in flight > aiodio_sparse: offset 165888 filesize 184320 inflight 9 > aiodio_sparse: io_getevent() returned 1 > aiodio_sparse: io_getevent() res 18432 res2 0 > io_submit() return 1 > AIO DIO write done unlinking file > dio_sparse done writing, kill children > aiodio_sparse 0 children had errors > > But when testing using aiocp using O_DIRECT to copy a file to > an already allocated file, the aiocp process hangs. I used i/o > size of 4k and that compeleted. Using i/o size of 1k and 2k, > the aiocp process hung during io_sumbit() and are unkillable. > Here are the stack traces: > > # ps -fu daniel | grep aiocp > daniel 1920 1 0 16:45 ? 00:00:07 aiocp -b 1k -n 1 -f DIRECT glibc-2.3.2.tar ff2 > daniel 2083 2037 0 17:00 pts/2 00:00:03 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 > > > aiocp D 00000001 1920 1 1902 (NOTLB) > e70abd04 00200086 c18dbc80 00000001 00000003 c02897fc 00000060 00200246 > f7cdb8b4 c16522f0 c18dbc80 0000309c 640a05eb 0000008b e6d9e660 > c0289a16 > f7cdb8b4 e87e95cc c18dbc80 00000000 00000001 e70abd10 c0123712 > e70aa000 > Call Trace: > [<c02897fc>] generic_unplug_device+0x50/0xbd > [<c0289a16>] blk_run_queues+0xa9/0x15c > [<c0123712>] io_schedule+0x26/0x30 > [<c0192242>] direct_io_worker+0x376/0x5ab > [<c014840f>] generic_file_direct_IO+0x70/0x89 > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > [<c014840f>] generic_file_direct_IO+0x70/0x89 > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > [<c0121b70>] schedule+0x3ac/0x7ef > [<c0145f48>] generic_file_aio_read+0x33/0x37 > [<c0194ad3>] aio_pread+0x34/0x5f > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > [<c019316f>] __aio_get_req+0x27/0x158 > [<c0194a9f>] aio_pread+0x0/0x5f > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > [<c0195110>] sys_io_submit+0xe1/0x194 > [<c03c29a7>] syscall_call+0x7/0xb > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > aiocp D 366EDC94 2083 2037 (NOTLB) > e758bd04 00200082 f71ba000 366edc94 00000161 c02897fc 00000060 366edc94 > 00000161 f71ba000 c18d3c80 000069a9 366f5a0e 00000161 e8d4acc0 c0289a16 > f7cdb8b4 e960465c c18d3c80 00000000 00000001 e758bd10 c0123712 e758a000 > Call Trace: > [<c02897fc>] generic_unplug_device+0x50/0xbd > [<c0289a16>] blk_run_queues+0xa9/0x15c > [<c0123712>] io_schedule+0x26/0x30 > [<c0192242>] direct_io_worker+0x376/0x5ab > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > [<c014840f>] generic_file_direct_IO+0x70/0x89 > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > [<c0259d3e>] write_chan+0x165/0x21e > [<c0145f48>] generic_file_aio_read+0x33/0x37 > [<c0194ad3>] aio_pread+0x34/0x5f > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > [<c019316f>] __aio_get_req+0x27/0x158 > [<c0194a9f>] aio_pread+0x0/0x5f > [<c02532ab>] tty_write+0x1e8/0x3b2 > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > [<c0195110>] sys_io_submit+0xe1/0x194 > [<c03c29a7>] syscall_call+0x7/0xb > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > > Daniel > > On Sun, 2003-11-16 at 21:25, Suparna Bhattacharya wrote: > > On Thu, Nov 13, 2003 at 02:03:58PM -0800, Daniel McNeil wrote: > > > Andrew, > > > > > > I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. > > > I tested using the test programs aiocp and aiodio_sparse. > > > (see http://developer.osdl.org/daniel/AIO/) > > > > > > Using aiocp with i/o sizes from 1k to 512k to copy files worked > > > without any errors or kernel debug messages. > > > > > > With 64k i/o, the aiodio_sparse program complete without any errors. > > > There are no kernel error messages, so that is good. > > > > > > There are still problems with non power of 2 i/o sizes using AIO and > > > O_DIRECT. It hangs with aio's that do not seem to complete. The test > > > does exit when hitting ^c and there are no kernel messages. Test output > > > below: > > > > Could you check if the following patch fixes the problem for you ? > > > > Regards > > Suparna > > > > -------------------------------------------------------------- > > > > With this patch, when the DIO code falls back to buffered i/o after > > having submitted part of the i/o, then buffered i/o is issued only > > for the remaining part of the request (i.e. the part not already > > covered by DIO). > > > > diff -ur pure-mm3/fs/direct-io.c linux-2.6.0-test9-mm3/fs/direct-io.c > > --- pure-mm3/fs/direct-io.c 2003-11-14 09:09:06.000000000 +0530 > > +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-17 09:00:47.000000000 +0530 > > @@ -74,6 +74,7 @@ > > been performed at the start of a > > write */ > > int pages_in_io; /* approximate total IO pages */ > > + size_t size; /* total request size (doesn't change)*/ > > sector_t block_in_file; /* Current offset into the underlying > > file in dio_block units. */ > > unsigned blocks_available; /* At block_in_file. changes */ > > @@ -226,7 +227,7 @@ > > dio_complete(dio, dio->block_in_file << dio->blkbits, > > dio->result); > > /* Complete AIO later if falling back to buffered i/o */ > > - if (dio->result != -ENOTBLK) { > > + if (dio->result >= dio->size || dio->rw == READ) { > > aio_complete(dio->iocb, dio->result, 0); > > kfree(dio); > > } else { > > @@ -889,6 +890,7 @@ > > dio->blkbits = blkbits; > > dio->blkfactor = inode->i_blkbits - blkbits; > > dio->start_zero_done = 0; > > + dio->size = 0; > > dio->block_in_file = offset >> blkbits; > > dio->blocks_available = 0; > > dio->cur_page = NULL; > > @@ -925,7 +927,7 @@ > > > > for (seg = 0; seg < nr_segs; seg++) { > > user_addr = (unsigned long)iov[seg].iov_base; > > - bytes = iov[seg].iov_len; > > + dio->size += bytes = iov[seg].iov_len; > > > > /* Index into the first page of the first block */ > > dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; > > @@ -956,6 +958,13 @@ > > } > > } /* end iovec loop */ > > > > + if (ret == -ENOTBLK && rw == WRITE) { > > + /* > > + * The remaining part of the request will be > > + * be handled by buffered I/O when we return > > + */ > > + ret = 0; > > + } > > /* > > * There may be some unwritten disk at the end of a part-written > > * fs-block-sized block. Go zero that now. > > @@ -986,19 +995,13 @@ > > */ > > if (dio->is_async) { > > if (ret == 0) > > - ret = dio->result; /* Bytes written */ > > - if (ret == -ENOTBLK) { > > - /* > > - * The request will be reissued via buffered I/O > > - * when we return; Any I/O already issued > > - * effectively becomes redundant. > > - */ > > - dio->result = ret; > > + ret = dio->result; > > + if (ret > 0 && dio->result < dio->size && rw == WRITE) { > > dio->waiter = current; > > } > > finished_one_bio(dio); /* This can free the dio */ > > blk_run_queues(); > > - if (ret == -ENOTBLK) { > > + if (dio->waiter) { > > /* > > * Wait for already issued I/O to drain out and > > * release its references to user-space pages > > @@ -1032,7 +1035,8 @@ > > } > > dio_complete(dio, offset, ret); > > /* We could have also come here on an AIO file extend */ > > - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) > > + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && > > + dio->result < dio->size)) > > aio_complete(iocb, ret, 0); > > kfree(dio); > > } > > diff -ur pure-mm3/mm/filemap.c linux-2.6.0-test9-mm3/mm/filemap.c > > --- pure-mm3/mm/filemap.c 2003-11-14 09:15:08.000000000 +0530 > > +++ linux-2.6.0-test9-mm3/mm/filemap.c 2003-11-15 11:11:16.000000000 +0530 > > @@ -1895,14 +1895,16 @@ > > */ > > if (written >= 0 && file->f_flags & O_SYNC) > > status = generic_osync_inode(inode, mapping, OSYNC_METADATA); > > - if (written >= 0 && !is_sync_kiocb(iocb)) > > + if (written >= count && !is_sync_kiocb(iocb)) > > written = -EIOCBQUEUED; > > - if (written != -ENOTBLK) > > + if (written < 0 || written >= count) > > goto out_status; > > /* > > * direct-io write to a hole: fall through to buffered I/O > > + * for completing the rest of the request. > > */ > > - written = 0; > > + pos += written; > > + count -= written; > > } > > > > buf = iov->iov_base; > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-18 1:37 ` Daniel McNeil @ 2003-11-18 11:55 ` Suparna Bhattacharya 2003-11-18 23:47 ` Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Suparna Bhattacharya @ 2003-11-18 11:55 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio I don't seem to able to recreate this at my end - even with 1k block sizes. Did you notice if this problem occurs without the latest patch ? Regards Suparna On Mon, Nov 17, 2003 at 05:37:14PM -0800, Daniel McNeil wrote: > Obviously, the ps output in my previous email showed that the hangs were > with 1k i/o sizes. > > More testing using 2k, 4k, 16k, 32k, 64k, 128k, 256k and 512k all > completed correctly. > > Even 11k and 17k worked. > > $ ls -l > -rw------- 1 daniel daniel 88289280 Jun 9 16:54 glibc-2.3.2.tar > -rw-rw-r-- 1 daniel daniel 88289280 Nov 17 17:32 ff2 > > > So, only 1k is hanging so far. > > Daniel > > On Mon, 2003-11-17 at 17:15, Daniel McNeil wrote: > > Suparna, > > > > Good news and bad news. Your patch does fix the non-power of two i/o > > size problems where AIO previously did not complete: > > > > $ ./aiodio_sparse -s 1751k -r 18k -w 11k > > $ aiodio_sparse -i 9 -dd -s 180k -r 18k -w 18k > > io_submit() return 9 > > aiodio_sparse: 9 i/o in flight > > aiodio_sparse: offset 165888 filesize 184320 inflight 9 > > aiodio_sparse: io_getevent() returned 1 > > aiodio_sparse: io_getevent() res 18432 res2 0 > > io_submit() return 1 > > AIO DIO write done unlinking file > > dio_sparse done writing, kill children > > aiodio_sparse 0 children had errors > > > > But when testing using aiocp using O_DIRECT to copy a file to > > an already allocated file, the aiocp process hangs. I used i/o > > size of 4k and that compeleted. Using i/o size of 1k and 2k, > > the aiocp process hung during io_sumbit() and are unkillable. > > Here are the stack traces: > > > > # ps -fu daniel | grep aiocp > > daniel 1920 1 0 16:45 ? 00:00:07 aiocp -b 1k -n 1 -f DIRECT glibc-2.3.2.tar ff2 > > daniel 2083 2037 0 17:00 pts/2 00:00:03 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 > > > > > > aiocp D 00000001 1920 1 1902 (NOTLB) > > e70abd04 00200086 c18dbc80 00000001 00000003 c02897fc 00000060 00200246 > > f7cdb8b4 c16522f0 c18dbc80 0000309c 640a05eb 0000008b e6d9e660 > > c0289a16 > > f7cdb8b4 e87e95cc c18dbc80 00000000 00000001 e70abd10 c0123712 > > e70aa000 > > Call Trace: > > [<c02897fc>] generic_unplug_device+0x50/0xbd > > [<c0289a16>] blk_run_queues+0xa9/0x15c > > [<c0123712>] io_schedule+0x26/0x30 > > [<c0192242>] direct_io_worker+0x376/0x5ab > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > > [<c0121b70>] schedule+0x3ac/0x7ef > > [<c0145f48>] generic_file_aio_read+0x33/0x37 > > [<c0194ad3>] aio_pread+0x34/0x5f > > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > > [<c019316f>] __aio_get_req+0x27/0x158 > > [<c0194a9f>] aio_pread+0x0/0x5f > > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > > [<c0195110>] sys_io_submit+0xe1/0x194 > > [<c03c29a7>] syscall_call+0x7/0xb > > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > > > > aiocp D 366EDC94 2083 2037 (NOTLB) > > e758bd04 00200082 f71ba000 366edc94 00000161 c02897fc 00000060 366edc94 > > 00000161 f71ba000 c18d3c80 000069a9 366f5a0e 00000161 e8d4acc0 c0289a16 > > f7cdb8b4 e960465c c18d3c80 00000000 00000001 e758bd10 c0123712 e758a000 > > Call Trace: > > [<c02897fc>] generic_unplug_device+0x50/0xbd > > [<c0289a16>] blk_run_queues+0xa9/0x15c > > [<c0123712>] io_schedule+0x26/0x30 > > [<c0192242>] direct_io_worker+0x376/0x5ab > > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > > [<c0259d3e>] write_chan+0x165/0x21e > > [<c0145f48>] generic_file_aio_read+0x33/0x37 > > [<c0194ad3>] aio_pread+0x34/0x5f > > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > > [<c019316f>] __aio_get_req+0x27/0x158 > > [<c0194a9f>] aio_pread+0x0/0x5f > > [<c02532ab>] tty_write+0x1e8/0x3b2 > > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > > [<c0195110>] sys_io_submit+0xe1/0x194 > > [<c03c29a7>] syscall_call+0x7/0xb > > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > > > > > > Daniel > > > > On Sun, 2003-11-16 at 21:25, Suparna Bhattacharya wrote: > > > On Thu, Nov 13, 2003 at 02:03:58PM -0800, Daniel McNeil wrote: > > > > Andrew, > > > > > > > > I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. > > > > I tested using the test programs aiocp and aiodio_sparse. > > > > (see http://developer.osdl.org/daniel/AIO/) > > > > > > > > Using aiocp with i/o sizes from 1k to 512k to copy files worked > > > > without any errors or kernel debug messages. > > > > > > > > With 64k i/o, the aiodio_sparse program complete without any errors. > > > > There are no kernel error messages, so that is good. > > > > > > > > There are still problems with non power of 2 i/o sizes using AIO and > > > > O_DIRECT. It hangs with aio's that do not seem to complete. The test > > > > does exit when hitting ^c and there are no kernel messages. Test output > > > > below: > > > > > > Could you check if the following patch fixes the problem for you ? > > > > > > Regards > > > Suparna > > > > > > -------------------------------------------------------------- > > > > > > With this patch, when the DIO code falls back to buffered i/o after > > > having submitted part of the i/o, then buffered i/o is issued only > > > for the remaining part of the request (i.e. the part not already > > > covered by DIO). > > > > > > diff -ur pure-mm3/fs/direct-io.c linux-2.6.0-test9-mm3/fs/direct-io.c > > > --- pure-mm3/fs/direct-io.c 2003-11-14 09:09:06.000000000 +0530 > > > +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-17 09:00:47.000000000 +0530 > > > @@ -74,6 +74,7 @@ > > > been performed at the start of a > > > write */ > > > int pages_in_io; /* approximate total IO pages */ > > > + size_t size; /* total request size (doesn't change)*/ > > > sector_t block_in_file; /* Current offset into the underlying > > > file in dio_block units. */ > > > unsigned blocks_available; /* At block_in_file. changes */ > > > @@ -226,7 +227,7 @@ > > > dio_complete(dio, dio->block_in_file << dio->blkbits, > > > dio->result); > > > /* Complete AIO later if falling back to buffered i/o */ > > > - if (dio->result != -ENOTBLK) { > > > + if (dio->result >= dio->size || dio->rw == READ) { > > > aio_complete(dio->iocb, dio->result, 0); > > > kfree(dio); > > > } else { > > > @@ -889,6 +890,7 @@ > > > dio->blkbits = blkbits; > > > dio->blkfactor = inode->i_blkbits - blkbits; > > > dio->start_zero_done = 0; > > > + dio->size = 0; > > > dio->block_in_file = offset >> blkbits; > > > dio->blocks_available = 0; > > > dio->cur_page = NULL; > > > @@ -925,7 +927,7 @@ > > > > > > for (seg = 0; seg < nr_segs; seg++) { > > > user_addr = (unsigned long)iov[seg].iov_base; > > > - bytes = iov[seg].iov_len; > > > + dio->size += bytes = iov[seg].iov_len; > > > > > > /* Index into the first page of the first block */ > > > dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; > > > @@ -956,6 +958,13 @@ > > > } > > > } /* end iovec loop */ > > > > > > + if (ret == -ENOTBLK && rw == WRITE) { > > > + /* > > > + * The remaining part of the request will be > > > + * be handled by buffered I/O when we return > > > + */ > > > + ret = 0; > > > + } > > > /* > > > * There may be some unwritten disk at the end of a part-written > > > * fs-block-sized block. Go zero that now. > > > @@ -986,19 +995,13 @@ > > > */ > > > if (dio->is_async) { > > > if (ret == 0) > > > - ret = dio->result; /* Bytes written */ > > > - if (ret == -ENOTBLK) { > > > - /* > > > - * The request will be reissued via buffered I/O > > > - * when we return; Any I/O already issued > > > - * effectively becomes redundant. > > > - */ > > > - dio->result = ret; > > > + ret = dio->result; > > > + if (ret > 0 && dio->result < dio->size && rw == WRITE) { > > > dio->waiter = current; > > > } > > > finished_one_bio(dio); /* This can free the dio */ > > > blk_run_queues(); > > > - if (ret == -ENOTBLK) { > > > + if (dio->waiter) { > > > /* > > > * Wait for already issued I/O to drain out and > > > * release its references to user-space pages > > > @@ -1032,7 +1035,8 @@ > > > } > > > dio_complete(dio, offset, ret); > > > /* We could have also come here on an AIO file extend */ > > > - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) > > > + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && > > > + dio->result < dio->size)) > > > aio_complete(iocb, ret, 0); > > > kfree(dio); > > > } > > > diff -ur pure-mm3/mm/filemap.c linux-2.6.0-test9-mm3/mm/filemap.c > > > --- pure-mm3/mm/filemap.c 2003-11-14 09:15:08.000000000 +0530 > > > +++ linux-2.6.0-test9-mm3/mm/filemap.c 2003-11-15 11:11:16.000000000 +0530 > > > @@ -1895,14 +1895,16 @@ > > > */ > > > if (written >= 0 && file->f_flags & O_SYNC) > > > status = generic_osync_inode(inode, mapping, OSYNC_METADATA); > > > - if (written >= 0 && !is_sync_kiocb(iocb)) > > > + if (written >= count && !is_sync_kiocb(iocb)) > > > written = -EIOCBQUEUED; > > > - if (written != -ENOTBLK) > > > + if (written < 0 || written >= count) > > > goto out_status; > > > /* > > > * direct-io write to a hole: fall through to buffered I/O > > > + * for completing the rest of the request. > > > */ > > > - written = 0; > > > + pos += written; > > > + count -= written; > > > } > > > > > > buf = iov->iov_base; > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-aio' in > > the body to majordomo@kvack.org. For more info on Linux AIO, > > see: http://www.kvack.org/aio/ > > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-18 11:55 ` Suparna Bhattacharya @ 2003-11-18 23:47 ` Daniel McNeil 2003-11-24 9:42 ` Suparna Bhattacharya 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-11-18 23:47 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Suparna, I was unable to reproduce the hang in io_submit() without your patch. I ran aiocp with 1k i/o size constantly for 2 hours and it never hung. I re-ran with your patch with both as-iosched and deadline and both hung in io_submit(). aiocp would run a few times, but I put the aiocp in a while loop and it hung on the 1st or 2nd time. It did get most of the way through copying the file before hanging. This is on a 2-proc to ide disks running ext3. Here is the stack trace and other info for as-iosched: daniel 2005 0.7 0.0 1388 384 pts/0 D 13:51 0:08 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 cat /proc/2005/wchan io_schedule aiocp D 00000001 2005 1870 (NOTLB) e53cfc08 00200086 c18d3c80 00000001 00000003 c02897fc 00000060 00200246 f7cdb8b4 c0191630 c18d3c80 0000bfc6 78d5d3e5 00000233 e4dc1980 c0289a16 f7cdb8b4 d92978e4 c18d3c80 00000000 00000001 e53cfc14 c0123712 e53ce000 Call Trace: [<c02897fc>] generic_unplug_device+0x50/0xbd [<c0191630>] dio_bio_add_page+0x34/0x79 [<c0289a16>] blk_run_queues+0xa9/0x15c [<c0123712>] io_schedule+0x26/0x30 [<c0192242>] direct_io_worker+0x376/0x5ab [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c014840f>] generic_file_direct_IO+0x70/0x89 [<c0147a80>] __generic_file_aio_write_nolock+0xa3a/0xda5 [<c025b049>] pty_write+0x1c8/0x1ca [<c01480a4>] generic_file_aio_write+0x7e/0x115 [<c0256d12>] opost+0x9e/0x1cf [<c01aa4a3>] ext3_file_write+0x3f/0xcc [<c0194b3a>] aio_pwrite+0x3c/0xad [<c0193bec>] aio_run_iocb+0xa6/0x1ed [<c019316f>] __aio_get_req+0x27/0x158 [<c0194afe>] aio_pwrite+0x0/0xad [<c02532ab>] tty_write+0x1e8/0x3b2 [<c0194f62>] io_submit_one+0x1ea/0x2b7 [<c0195110>] sys_io_submit+0xe1/0x194 [<c03c29a7>] syscall_call+0x7/0xb For deadline iosched: daniel 1889 0.1 0.0 1388 384 pts/0 D 15:12 0:01 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 $ cat /proc/1889/wchan io_schedule $ cat /sys/block/hdb/stat 209058 23145 45744 58542 209022 22069 0 20758 45210 aiocp D 0AD7701D 1889 1752 (NOTLB) ee2ddd04 00200086 f75e6660 0ad7701d 0000004e 00200282 ebd37cbc 0ad7701d 0000004e f75e6660 c18d3c80 00060539 0ad7701d 0000004e f75e6000 0000006b ee2ddd10 c0192212 c18d3c80 00000000 00000001 ee2ddd10 c0123712 ee2dc000 Call Trace: [<c0192212>] direct_io_worker+0x346/0x5ab [<c0123712>] io_schedule+0x26/0x30 [<c0192242>] direct_io_worker+0x376/0x5ab [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf [<c014840f>] generic_file_direct_IO+0x70/0x89 [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff [<c0259d3e>] write_chan+0x165/0x21e [<c0145f48>] generic_file_aio_read+0x33/0x37 [<c0194ad3>] aio_pread+0x34/0x5f [<c0193bec>] aio_run_iocb+0xa6/0x1ed [<c019316f>] __aio_get_req+0x27/0x158 [<c0194a9f>] aio_pread+0x0/0x5f [<c02532ab>] tty_write+0x1e8/0x3b2 [<c0194f62>] io_submit_one+0x1ea/0x2b7 [<c0195110>] sys_io_submit+0xe1/0x194 [<c03c29a7>] syscall_call+0x7/0xb The hung processes are stuck in the 'D' state and unkillable, of course. I would appear something is wrong with your patch. Any ideas? Daniel On Tue, 2003-11-18 at 03:55, Suparna Bhattacharya wrote: > I don't seem to able to recreate this at my end - even with 1k > block sizes. Did you notice if this problem occurs without > the latest patch ? > > Regards > Suparna > > On Mon, Nov 17, 2003 at 05:37:14PM -0800, Daniel McNeil wrote: > > Obviously, the ps output in my previous email showed that the hangs were > > with 1k i/o sizes. > > > > More testing using 2k, 4k, 16k, 32k, 64k, 128k, 256k and 512k all > > completed correctly. > > > > Even 11k and 17k worked. > > > > $ ls -l > > -rw------- 1 daniel daniel 88289280 Jun 9 16:54 glibc-2.3.2.tar > > -rw-rw-r-- 1 daniel daniel 88289280 Nov 17 17:32 ff2 > > > > > > So, only 1k is hanging so far. > > > > Daniel > > > > On Mon, 2003-11-17 at 17:15, Daniel McNeil wrote: > > > Suparna, > > > > > > Good news and bad news. Your patch does fix the non-power of two i/o > > > size problems where AIO previously did not complete: > > > > > > $ ./aiodio_sparse -s 1751k -r 18k -w 11k > > > $ aiodio_sparse -i 9 -dd -s 180k -r 18k -w 18k > > > io_submit() return 9 > > > aiodio_sparse: 9 i/o in flight > > > aiodio_sparse: offset 165888 filesize 184320 inflight 9 > > > aiodio_sparse: io_getevent() returned 1 > > > aiodio_sparse: io_getevent() res 18432 res2 0 > > > io_submit() return 1 > > > AIO DIO write done unlinking file > > > dio_sparse done writing, kill children > > > aiodio_sparse 0 children had errors > > > > > > But when testing using aiocp using O_DIRECT to copy a file to > > > an already allocated file, the aiocp process hangs. I used i/o > > > size of 4k and that compeleted. Using i/o size of 1k and 2k, > > > the aiocp process hung during io_sumbit() and are unkillable. > > > Here are the stack traces: > > > > > > # ps -fu daniel | grep aiocp > > > daniel 1920 1 0 16:45 ? 00:00:07 aiocp -b 1k -n 1 -f DIRECT glibc-2.3.2.tar ff2 > > > daniel 2083 2037 0 17:00 pts/2 00:00:03 aiocp -dd -b 1k -n 8 -f DIRECT glibc-2.3.2.tar ff2 > > > > > > > > > aiocp D 00000001 1920 1 1902 (NOTLB) > > > e70abd04 00200086 c18dbc80 00000001 00000003 c02897fc 00000060 00200246 > > > f7cdb8b4 c16522f0 c18dbc80 0000309c 640a05eb 0000008b e6d9e660 > > > c0289a16 > > > f7cdb8b4 e87e95cc c18dbc80 00000000 00000001 e70abd10 c0123712 > > > e70aa000 > > > Call Trace: > > > [<c02897fc>] generic_unplug_device+0x50/0xbd > > > [<c0289a16>] blk_run_queues+0xa9/0x15c > > > [<c0123712>] io_schedule+0x26/0x30 > > > [<c0192242>] direct_io_worker+0x376/0x5ab > > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > > > [<c0121b70>] schedule+0x3ac/0x7ef > > > [<c0145f48>] generic_file_aio_read+0x33/0x37 > > > [<c0194ad3>] aio_pread+0x34/0x5f > > > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > > > [<c019316f>] __aio_get_req+0x27/0x158 > > > [<c0194a9f>] aio_pread+0x0/0x5f > > > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > > > [<c0195110>] sys_io_submit+0xe1/0x194 > > > [<c03c29a7>] syscall_call+0x7/0xb > > > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > > > > > > > aiocp D 366EDC94 2083 2037 (NOTLB) > > > e758bd04 00200082 f71ba000 366edc94 00000161 c02897fc 00000060 366edc94 > > > 00000161 f71ba000 c18d3c80 000069a9 366f5a0e 00000161 e8d4acc0 c0289a16 > > > f7cdb8b4 e960465c c18d3c80 00000000 00000001 e758bd10 c0123712 e758a000 > > > Call Trace: > > > [<c02897fc>] generic_unplug_device+0x50/0xbd > > > [<c0289a16>] blk_run_queues+0xa9/0x15c > > > [<c0123712>] io_schedule+0x26/0x30 > > > [<c0192242>] direct_io_worker+0x376/0x5ab > > > [<c019264a>] __blockdev_direct_IO+0x1d3/0x2d5 > > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > > [<c01ad72d>] ext3_direct_IO+0xc0/0x1e1 > > > [<c01ac73e>] ext3_direct_io_get_blocks+0x0/0xbf > > > [<c014840f>] generic_file_direct_IO+0x70/0x89 > > > [<c0145e11>] __generic_file_aio_read+0xfb/0x1ff > > > [<c0259d3e>] write_chan+0x165/0x21e > > > [<c0145f48>] generic_file_aio_read+0x33/0x37 > > > [<c0194ad3>] aio_pread+0x34/0x5f > > > [<c0193bec>] aio_run_iocb+0xa6/0x1ed > > > [<c019316f>] __aio_get_req+0x27/0x158 > > > [<c0194a9f>] aio_pread+0x0/0x5f > > > [<c02532ab>] tty_write+0x1e8/0x3b2 > > > [<c0194f62>] io_submit_one+0x1ea/0x2b7 > > > [<c0195110>] sys_io_submit+0xe1/0x194 > > > [<c03c29a7>] syscall_call+0x7/0xb > > > [<c03c007b>] rpc_depopulate+0x1aa/0x24b > > > > > > > > > > > > Daniel > > > > > > On Sun, 2003-11-16 at 21:25, Suparna Bhattacharya wrote: > > > > On Thu, Nov 13, 2003 at 02:03:58PM -0800, Daniel McNeil wrote: > > > > > Andrew, > > > > > > > > > > I'm testing test9-mm3 on a 2-proc Xeon with a ext3 file system. > > > > > I tested using the test programs aiocp and aiodio_sparse. > > > > > (see http://developer.osdl.org/daniel/AIO/) > > > > > > > > > > Using aiocp with i/o sizes from 1k to 512k to copy files worked > > > > > without any errors or kernel debug messages. > > > > > > > > > > With 64k i/o, the aiodio_sparse program complete without any errors. > > > > > There are no kernel error messages, so that is good. > > > > > > > > > > There are still problems with non power of 2 i/o sizes using AIO and > > > > > O_DIRECT. It hangs with aio's that do not seem to complete. The test > > > > > does exit when hitting ^c and there are no kernel messages. Test output > > > > > below: > > > > > > > > Could you check if the following patch fixes the problem for you ? > > > > > > > > Regards > > > > Suparna > > > > > > > > -------------------------------------------------------------- > > > > > > > > With this patch, when the DIO code falls back to buffered i/o after > > > > having submitted part of the i/o, then buffered i/o is issued only > > > > for the remaining part of the request (i.e. the part not already > > > > covered by DIO). > > > > > > > > diff -ur pure-mm3/fs/direct-io.c linux-2.6.0-test9-mm3/fs/direct-io.c > > > > --- pure-mm3/fs/direct-io.c 2003-11-14 09:09:06.000000000 +0530 > > > > +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-17 09:00:47.000000000 +0530 > > > > @@ -74,6 +74,7 @@ > > > > been performed at the start of a > > > > write */ > > > > int pages_in_io; /* approximate total IO pages */ > > > > + size_t size; /* total request size (doesn't change)*/ > > > > sector_t block_in_file; /* Current offset into the underlying > > > > file in dio_block units. */ > > > > unsigned blocks_available; /* At block_in_file. changes */ > > > > @@ -226,7 +227,7 @@ > > > > dio_complete(dio, dio->block_in_file << dio->blkbits, > > > > dio->result); > > > > /* Complete AIO later if falling back to buffered i/o */ > > > > - if (dio->result != -ENOTBLK) { > > > > + if (dio->result >= dio->size || dio->rw == READ) { > > > > aio_complete(dio->iocb, dio->result, 0); > > > > kfree(dio); > > > > } else { > > > > @@ -889,6 +890,7 @@ > > > > dio->blkbits = blkbits; > > > > dio->blkfactor = inode->i_blkbits - blkbits; > > > > dio->start_zero_done = 0; > > > > + dio->size = 0; > > > > dio->block_in_file = offset >> blkbits; > > > > dio->blocks_available = 0; > > > > dio->cur_page = NULL; > > > > @@ -925,7 +927,7 @@ > > > > > > > > for (seg = 0; seg < nr_segs; seg++) { > > > > user_addr = (unsigned long)iov[seg].iov_base; > > > > - bytes = iov[seg].iov_len; > > > > + dio->size += bytes = iov[seg].iov_len; > > > > > > > > /* Index into the first page of the first block */ > > > > dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; > > > > @@ -956,6 +958,13 @@ > > > > } > > > > } /* end iovec loop */ > > > > > > > > + if (ret == -ENOTBLK && rw == WRITE) { > > > > + /* > > > > + * The remaining part of the request will be > > > > + * be handled by buffered I/O when we return > > > > + */ > > > > + ret = 0; > > > > + } > > > > /* > > > > * There may be some unwritten disk at the end of a part-written > > > > * fs-block-sized block. Go zero that now. > > > > @@ -986,19 +995,13 @@ > > > > */ > > > > if (dio->is_async) { > > > > if (ret == 0) > > > > - ret = dio->result; /* Bytes written */ > > > > - if (ret == -ENOTBLK) { > > > > - /* > > > > - * The request will be reissued via buffered I/O > > > > - * when we return; Any I/O already issued > > > > - * effectively becomes redundant. > > > > - */ > > > > - dio->result = ret; > > > > + ret = dio->result; > > > > + if (ret > 0 && dio->result < dio->size && rw == WRITE) { > > > > dio->waiter = current; > > > > } > > > > finished_one_bio(dio); /* This can free the dio */ > > > > blk_run_queues(); > > > > - if (ret == -ENOTBLK) { > > > > + if (dio->waiter) { > > > > /* > > > > * Wait for already issued I/O to drain out and > > > > * release its references to user-space pages > > > > @@ -1032,7 +1035,8 @@ > > > > } > > > > dio_complete(dio, offset, ret); > > > > /* We could have also come here on an AIO file extend */ > > > > - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) > > > > + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && > > > > + dio->result < dio->size)) > > > > aio_complete(iocb, ret, 0); > > > > kfree(dio); > > > > } > > > > diff -ur pure-mm3/mm/filemap.c linux-2.6.0-test9-mm3/mm/filemap.c > > > > --- pure-mm3/mm/filemap.c 2003-11-14 09:15:08.000000000 +0530 > > > > +++ linux-2.6.0-test9-mm3/mm/filemap.c 2003-11-15 11:11:16.000000000 +0530 > > > > @@ -1895,14 +1895,16 @@ > > > > */ > > > > if (written >= 0 && file->f_flags & O_SYNC) > > > > status = generic_osync_inode(inode, mapping, OSYNC_METADATA); > > > > - if (written >= 0 && !is_sync_kiocb(iocb)) > > > > + if (written >= count && !is_sync_kiocb(iocb)) > > > > written = -EIOCBQUEUED; > > > > - if (written != -ENOTBLK) > > > > + if (written < 0 || written >= count) > > > > goto out_status; > > > > /* > > > > * direct-io write to a hole: fall through to buffered I/O > > > > + * for completing the rest of the request. > > > > */ > > > > - written = 0; > > > > + pos += written; > > > > + count -= written; > > > > } > > > > > > > > buf = iov->iov_base; > > > > > > -- > > > To unsubscribe, send a message with 'unsubscribe linux-aio' in > > > the body to majordomo@kvack.org. For more info on Linux AIO, > > > see: http://www.kvack.org/aio/ > > > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-aio' in > > the body to majordomo@kvack.org. For more info on Linux AIO, > > see: http://www.kvack.org/aio/ > > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 - AIO test results 2003-11-18 23:47 ` Daniel McNeil @ 2003-11-24 9:42 ` Suparna Bhattacharya 2003-11-25 23:49 ` [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Suparna Bhattacharya @ 2003-11-24 9:42 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio On Tue, Nov 18, 2003 at 03:47:53PM -0800, Daniel McNeil wrote: > Suparna, > > I was unable to reproduce the hang in io_submit() without your patch. > I ran aiocp with 1k i/o size constantly for 2 hours and it never hung. > > I re-ran with your patch with both as-iosched and deadline and both > hung in io_submit(). aiocp would run a few times, but I put the > aiocp in a while loop and it hung on the 1st or 2nd time. It > did get most of the way through copying the file before hanging. > This is on a 2-proc to ide disks running ext3. > Found one race ... not sure if its the one causing the hangs you see. The attached patch is not a complete fix (there is one other race to close), but it would be interesting to see if this makes any difference for you. Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India ------------------------------------------------------ Don't access dio fields if its possible that the dio could already have been freed asynchronously during i/o completion. Fixme: This still leaves a window between decrement of bio_count and accessing dio->waiter during i/o completion wherein the dio could get freed by the submission path. --- pure-mm3/fs/direct-io.c 2003-11-24 13:00:33.000000000 +0530 +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-24 14:15:30.000000000 +0530 @@ -994,14 +995,17 @@ * reflect the number of to-be-processed BIOs. */ if (dio->is_async) { - if (ret == 0) - ret = dio->result; - if (ret > 0 && dio->result < dio->size && rw == WRITE) { + int should_wait = 0; + + if (dio->result < dio->size && rw == WRITE) { dio->waiter = current; + should_wait = 1; } + if (ret == 0) + ret = dio->result; finished_one_bio(dio); /* This can free the dio */ blk_run_queues(); - if (dio->waiter) { + if (should_wait) { /* * Wait for already issued I/O to drain out and * release its references to user-space pages @@ -1013,7 +1017,7 @@ set_current_state(TASK_UNINTERRUPTIBLE); } set_current_state(TASK_RUNNING); - dio->waiter = NULL; + kfree(dio); } } else { finished_one_bio(dio); ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-11-24 9:42 ` Suparna Bhattacharya @ 2003-11-25 23:49 ` Daniel McNeil 2003-11-26 7:55 ` Suparna Bhattacharya 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-11-25 23:49 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio [-- Attachment #1: Type: text/plain, Size: 1861 bytes --] Suparna, Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which was helping me see problems because the the freed dio was getting poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is very good at catching these. I updated your AIO fallback patch plus your AIO race plus I fixed the bio_count decrement fix. This patch has all three fixes and it is working for me. I fixed the bio_count race, by changing bio_list_lock into bio_lock and using that for all the bio fields. I changed bio_count and bios_in_flight from atomics into int. They are now proctected by the bio_lock. I fixed the race, by in finished_one_bio() by leaving the bio_count at 1 until after the dio_complete() and then do the bio_count decrement and wakeup holding the bio_lock. Take a look, give it a try, and let me know what you think. I've tested this on my 2-way and so far all my tests have past. I have more testing to do, but this is working better. Thanks, Daniel On Mon, 2003-11-24 at 01:42, Suparna Bhattacharya wrote: > On Tue, Nov 18, 2003 at 03:47:53PM -0800, Daniel McNeil wrote: > > Suparna, > > > > I was unable to reproduce the hang in io_submit() without your patch. > > I ran aiocp with 1k i/o size constantly for 2 hours and it never hung. > > > > I re-ran with your patch with both as-iosched and deadline and both > > hung in io_submit(). aiocp would run a few times, but I put the > > aiocp in a while loop and it hung on the 1st or 2nd time. It > > did get most of the way through copying the file before hanging. > > This is on a 2-proc to ide disks running ext3. > > > > Found one race ... not sure if its the one causing the hangs > you see. The attached patch is not a complete fix (there is one > other race to close), but it would be interesting to see if > this makes any difference for you. > > Regards > Suparna [-- Attachment #2: 2.6.0-test9-mm5.aio-dio-fallback-bio_count-race.patch --] [-- Type: text/x-patch, Size: 9088 bytes --] diff -rupN -X /home/daniel/dontdiff linux-2.6.0-test9-mm5/fs/direct-io.c linux-2.6.0-test9-mm5.ddm/fs/direct-io.c --- linux-2.6.0-test9-mm5/fs/direct-io.c 2003-11-24 09:06:05.000000000 -0800 +++ linux-2.6.0-test9-mm5.ddm/fs/direct-io.c 2003-11-25 14:52:43.566103685 -0800 @@ -74,6 +74,7 @@ struct dio { been performed at the start of a write */ int pages_in_io; /* approximate total IO pages */ + size_t size; /* total request size (doesn't change)*/ sector_t block_in_file; /* Current offset into the underlying file in dio_block units. */ unsigned blocks_available; /* At block_in_file. changes */ @@ -115,9 +116,9 @@ struct dio { int page_errors; /* errno from get_user_pages() */ /* BIO completion state */ - atomic_t bio_count; /* nr bios to be completed */ - atomic_t bios_in_flight; /* nr bios in flight */ - spinlock_t bio_list_lock; /* protects bio_list */ + spinlock_t bio_lock; /* protects BIO fields below */ + int bio_count; /* nr bios to be completed */ + int bios_in_flight; /* nr bios in flight */ struct bio *bio_list; /* singly linked via bi_private */ struct task_struct *waiter; /* waiting task (NULL if none) */ @@ -221,20 +222,38 @@ static void dio_complete(struct dio *dio */ static void finished_one_bio(struct dio *dio) { - if (atomic_dec_and_test(&dio->bio_count)) { + unsigned long flags; + + spin_lock_irqsave(&dio->bio_lock, flags); + if (dio->bio_count == 1) { if (dio->is_async) { + /* + * Last reference to the dio is going away. + * Drop spinlock and complete the DIO. + */ + spin_unlock_irqrestore(&dio->bio_lock, flags); dio_complete(dio, dio->block_in_file << dio->blkbits, dio->result); /* Complete AIO later if falling back to buffered i/o */ - if (dio->result != -ENOTBLK) { + if (dio->result >= dio->size || dio->rw == READ) { aio_complete(dio->iocb, dio->result, 0); kfree(dio); + return; } else { + /* + * Falling back to buffered + */ + spin_lock_irqsave(&dio->bio_lock, flags); + dio->bio_count--; if (dio->waiter) wake_up_process(dio->waiter); + spin_unlock_irqrestore(&dio->bio_lock, flags); + return; } } } + dio->bio_count--; + spin_unlock_irqrestore(&dio->bio_lock, flags); } static int dio_bio_complete(struct dio *dio, struct bio *bio); @@ -268,13 +287,13 @@ static int dio_bio_end_io(struct bio *bi if (bio->bi_size) return 1; - spin_lock_irqsave(&dio->bio_list_lock, flags); + spin_lock_irqsave(&dio->bio_lock, flags); bio->bi_private = dio->bio_list; dio->bio_list = bio; - atomic_dec(&dio->bios_in_flight); - if (dio->waiter && atomic_read(&dio->bios_in_flight) == 0) + dio->bios_in_flight--; + if (dio->waiter && dio->bios_in_flight == 0) wake_up_process(dio->waiter); - spin_unlock_irqrestore(&dio->bio_list_lock, flags); + spin_unlock_irqrestore(&dio->bio_lock, flags); return 0; } @@ -307,10 +326,13 @@ dio_bio_alloc(struct dio *dio, struct bl static void dio_bio_submit(struct dio *dio) { struct bio *bio = dio->bio; + unsigned long flags; bio->bi_private = dio; - atomic_inc(&dio->bio_count); - atomic_inc(&dio->bios_in_flight); + spin_lock_irqsave(&dio->bio_lock, flags); + dio->bio_count++; + dio->bios_in_flight++; + spin_unlock_irqrestore(&dio->bio_lock, flags); if (dio->is_async && dio->rw == READ) bio_set_pages_dirty(bio); submit_bio(dio->rw, bio); @@ -336,22 +358,22 @@ static struct bio *dio_await_one(struct unsigned long flags; struct bio *bio; - spin_lock_irqsave(&dio->bio_list_lock, flags); + spin_lock_irqsave(&dio->bio_lock, flags); while (dio->bio_list == NULL) { set_current_state(TASK_UNINTERRUPTIBLE); if (dio->bio_list == NULL) { dio->waiter = current; - spin_unlock_irqrestore(&dio->bio_list_lock, flags); + spin_unlock_irqrestore(&dio->bio_lock, flags); blk_run_queues(); io_schedule(); - spin_lock_irqsave(&dio->bio_list_lock, flags); + spin_lock_irqsave(&dio->bio_lock, flags); dio->waiter = NULL; } set_current_state(TASK_RUNNING); } bio = dio->bio_list; dio->bio_list = bio->bi_private; - spin_unlock_irqrestore(&dio->bio_list_lock, flags); + spin_unlock_irqrestore(&dio->bio_lock, flags); return bio; } @@ -393,7 +415,12 @@ static int dio_await_completion(struct d if (dio->bio) dio_bio_submit(dio); - while (atomic_read(&dio->bio_count)) { + /* + * The bio_lock is not held for the read of bio_count. + * This is ok since it is the dio_bio_complete() that changes + * bio_count. + */ + while (dio->bio_count) { struct bio *bio = dio_await_one(dio); int ret2; @@ -420,10 +447,10 @@ static int dio_bio_reap(struct dio *dio) unsigned long flags; struct bio *bio; - spin_lock_irqsave(&dio->bio_list_lock, flags); + spin_lock_irqsave(&dio->bio_lock, flags); bio = dio->bio_list; dio->bio_list = bio->bi_private; - spin_unlock_irqrestore(&dio->bio_list_lock, flags); + spin_unlock_irqrestore(&dio->bio_lock, flags); ret = dio_bio_complete(dio, bio); } dio->reap_counter = 0; @@ -889,6 +916,7 @@ direct_io_worker(int rw, struct kiocb *i dio->blkbits = blkbits; dio->blkfactor = inode->i_blkbits - blkbits; dio->start_zero_done = 0; + dio->size = 0; dio->block_in_file = offset >> blkbits; dio->blocks_available = 0; dio->cur_page = NULL; @@ -913,9 +941,9 @@ direct_io_worker(int rw, struct kiocb *i * (or synchronous) device could take the count to zero while we're * still submitting BIOs. */ - atomic_set(&dio->bio_count, 1); - atomic_set(&dio->bios_in_flight, 0); - spin_lock_init(&dio->bio_list_lock); + dio->bio_count = 1; + dio->bios_in_flight = 0; + spin_lock_init(&dio->bio_lock); dio->bio_list = NULL; dio->waiter = NULL; @@ -925,7 +953,7 @@ direct_io_worker(int rw, struct kiocb *i for (seg = 0; seg < nr_segs; seg++) { user_addr = (unsigned long)iov[seg].iov_base; - bytes = iov[seg].iov_len; + dio->size += bytes = iov[seg].iov_len; /* Index into the first page of the first block */ dio->first_block_in_page = (user_addr & ~PAGE_MASK) >> blkbits; @@ -956,6 +984,13 @@ direct_io_worker(int rw, struct kiocb *i } } /* end iovec loop */ + if (ret == -ENOTBLK && rw == WRITE) { + /* + * The remaining part of the request will be + * be handled by buffered I/O when we return + */ + ret = 0; + } /* * There may be some unwritten disk at the end of a part-written * fs-block-sized block. Go zero that now. @@ -985,32 +1020,35 @@ direct_io_worker(int rw, struct kiocb *i * reflect the number of to-be-processed BIOs. */ if (dio->is_async) { - if (ret == 0) - ret = dio->result; /* Bytes written */ - if (ret == -ENOTBLK) { - /* - * The request will be reissued via buffered I/O - * when we return; Any I/O already issued - * effectively becomes redundant. - */ - dio->result = ret; + int should_wait = 0; + + if (dio->result < dio->size && rw == WRITE) { dio->waiter = current; + should_wait = 1; } + if (ret == 0) + ret = dio->result; finished_one_bio(dio); /* This can free the dio */ blk_run_queues(); - if (ret == -ENOTBLK) { + if (should_wait) { + unsigned long flags; /* * Wait for already issued I/O to drain out and * release its references to user-space pages * before returning to fallback on buffered I/O */ + + spin_lock_irqsave(&dio->bio_lock, flags); set_current_state(TASK_UNINTERRUPTIBLE); - while (atomic_read(&dio->bio_count)) { + while (dio->bio_count) { + spin_unlock_irqrestore(&dio->bio_lock, flags); io_schedule(); + spin_lock_irqsave(&dio->bio_lock, flags); set_current_state(TASK_UNINTERRUPTIBLE); } + spin_unlock_irqrestore(&dio->bio_lock, flags); set_current_state(TASK_RUNNING); - dio->waiter = NULL; + kfree(dio); } } else { finished_one_bio(dio); @@ -1032,7 +1070,8 @@ direct_io_worker(int rw, struct kiocb *i } dio_complete(dio, offset, ret); /* We could have also come here on an AIO file extend */ - if (!is_sync_kiocb(iocb) && (ret != -ENOTBLK)) + if (!is_sync_kiocb(iocb) && !(rw == WRITE && ret >= 0 && + dio->result < dio->size)) aio_complete(iocb, ret, 0); kfree(dio); } diff -rupN -X /home/daniel/dontdiff linux-2.6.0-test9-mm5/mm/filemap.c linux-2.6.0-test9-mm5.ddm/mm/filemap.c --- linux-2.6.0-test9-mm5/mm/filemap.c 2003-11-24 09:06:06.000000000 -0800 +++ linux-2.6.0-test9-mm5.ddm/mm/filemap.c 2003-11-21 14:20:09.000000000 -0800 @@ -1908,14 +1908,16 @@ __generic_file_aio_write_nolock(struct k */ if (written >= 0 && file->f_flags & O_SYNC) status = generic_osync_inode(inode, mapping, OSYNC_METADATA); - if (written >= 0 && !is_sync_kiocb(iocb)) + if (written >= count && !is_sync_kiocb(iocb)) written = -EIOCBQUEUED; - if (written != -ENOTBLK) + if (written < 0 || written >= count) goto out_status; /* * direct-io write to a hole: fall through to buffered I/O + * for completing the rest of the request. */ - written = 0; + pos += written; + count -= written; } buf = iov->iov_base; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-11-25 23:49 ` [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch Daniel McNeil @ 2003-11-26 7:55 ` Suparna Bhattacharya 2003-12-02 1:35 ` Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Suparna Bhattacharya @ 2003-11-26 7:55 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio On Tue, Nov 25, 2003 at 03:49:31PM -0800, Daniel McNeil wrote: > Suparna, > > Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which > was helping me see problems because the the freed dio was getting > poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is > very good at catching these. Ah I see - perhaps that explains why neither Janet nor I could recreate the problem that you were hitting so easily. So we should probably try running with CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC as well. > > I updated your AIO fallback patch plus your AIO race plus I fixed > the bio_count decrement fix. This patch has all three fixes and > it is working for me. > > I fixed the bio_count race, by changing bio_list_lock into bio_lock > and using that for all the bio fields. I changed bio_count and > bios_in_flight from atomics into int. They are now proctected by > the bio_lock. I fixed the race, by in finished_one_bio() by > leaving the bio_count at 1 until after the dio_complete() > and then do the bio_count decrement and wakeup holding the bio_lock. > > Take a look, give it a try, and let me know what you think. I had been trying a slightly different kind of fix -- appended is the updated version of the patch I last posted. It uses the bio_list_lock to protect the dio->waiter field, which finished_one_bio sets back to NULL after it has issued the wakeup; and the code that waits for i/o to drain out checks the dio->waiter field instead of bio_count. This might not seem very obvious given the nomenclature of the bio_list_lock, so I was holding back wondering if it could be improved. Your approach looks clearer in that sense -- its pretty unambiguous about what lock protects what fields. The only thing that bothers me (and this is what I was trying to avoid in my patch) is the increased use of spin_lock_irq 's (overhead of turning interrupts off and on) instead of simple atomic inc/dec in most places. Thoughts ? Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India ------------------------------------ Don't access dio fields if its possible that the dio could already have been freed asynchronously during i/o completion. The dio->bio_list_lock protects the dio->waiter field as in the case of synchronous i/o. --- pure-mm3/fs/direct-io.c 2003-11-24 13:00:33.000000000 +0530 +++ linux-2.6.0-test9-mm3/fs/direct-io.c 2003-11-25 14:08:26.000000000 +0530 @@ -231,8 +231,17 @@ aio_complete(dio->iocb, dio->result, 0); kfree(dio); } else { - if (dio->waiter) - wake_up_process(dio->waiter); + struct task_struct *waiter; + unsigned long flags; + + spin_lock_irqsave(&dio->bio_list_lock, flags); + waiter = dio->waiter; + if (waiter) { + dio->waiter = NULL; + wake_up_process(waiter); + } + spin_unlock_irqrestore(&dio->bio_list_lock, + flags); } } } @@ -994,26 +1004,35 @@ * reflect the number of to-be-processed BIOs. */ if (dio->is_async) { - if (ret == 0) - ret = dio->result; - if (ret > 0 && dio->result < dio->size && rw == WRITE) { + int should_wait = 0; + + if (dio->result < dio->size && rw == WRITE) { dio->waiter = current; + should_wait = 1; } + if (ret == 0) + ret = dio->result; finished_one_bio(dio); /* This can free the dio */ blk_run_queues(); - if (dio->waiter) { + if (should_wait) { + unsigned long flags; /* * Wait for already issued I/O to drain out and * release its references to user-space pages * before returning to fallback on buffered I/O */ + spin_lock_irqsave(&dio->bio_list_lock, flags); set_current_state(TASK_UNINTERRUPTIBLE); - while (atomic_read(&dio->bio_count)) { + while (dio->waiter) { + spin_unlock_irqrestore(&dio->bio_list_lock, + flags); io_schedule(); set_current_state(TASK_UNINTERRUPTIBLE); + spin_lock_irqsave(&dio->bio_list_lock, flags); } set_current_state(TASK_RUNNING); - dio->waiter = NULL; + spin_unlock_irqrestore(&dio->bio_list_lock, flags); + kfree(dio); } } else { finished_one_bio(dio); ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-11-26 7:55 ` Suparna Bhattacharya @ 2003-12-02 1:35 ` Daniel McNeil 2003-12-02 15:25 ` Suparna Bhattacharya 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-12-02 1:35 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Suparna, Sorry I did not respond sooner, I was on vacation. Your patch should also fix the problem. I like mine with the cleaner locking. I am not sure your approach has less overhead. At least on x86, cli/sti are fairly inexpensive. The locked xchange or locked inc/dec is what is expensive (from what I understand). So comparing: my patch: Your patch: dio_bio_submit() spin_lock() atomic_inc(bio_count); bio_count++ atomic_inc(bios_in_flight); bios_in_flight++ spin_unlock My guess is that the spin_lock/spin_unlock is faster than 2 atomic_inc's since it is only 1 locked operation (spin_lock) verses 2 (atomic_inc's) finished_one_bio() (normal case) My patch: spin_lock() atomic_dec_and_test(bio_count) bio_count-- spin_unlock() 1 locked instruction each, so very close -- atomic_dec_and_test() does not disable interrupts, so it is probabably a little bit faster. finished_one-bio (fallback case): spin_lock() spin_lock() bio_count--; dio->waiter = null spin_unlock() spin_unlock() Both approaches are the same. dio_bio_complete() spin_lock() spin_lock() bios_in_flight-- atomic_dec() spin_unlock spin_unlock() My patch is faster since it removed 1 locked instruction. Conclusion: My guess would be that both approaches are close, but my patch has less locked instructions but does disable interrupts more. My preference is for the cleaner locking approach that is easier to understand and modify in the future. Daniel On Tue, 2003-11-25 at 23:55, Suparna Bhattacharya wrote: > On Tue, Nov 25, 2003 at 03:49:31PM -0800, Daniel McNeil wrote: > > Suparna, > > > > Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which > > was helping me see problems because the the freed dio was getting > > poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is > > very good at catching these. > > Ah I see - perhaps that explains why neither Janet nor I could > recreate the problem that you were hitting so easily. So we > should probably try running with CONFIG_DEBUG_SLAB and > CONFIG_DEBUG_PAGEALLOC as well. > > > > > I updated your AIO fallback patch plus your AIO race plus I fixed > > the bio_count decrement fix. This patch has all three fixes and > > it is working for me. > > > > I fixed the bio_count race, by changing bio_list_lock into bio_lock > > and using that for all the bio fields. I changed bio_count and > > bios_in_flight from atomics into int. They are now proctected by > > the bio_lock. I fixed the race, by in finished_one_bio() by > > leaving the bio_count at 1 until after the dio_complete() > > and then do the bio_count decrement and wakeup holding the bio_lock. > > > > Take a look, give it a try, and let me know what you think. > > I had been trying a slightly different kind of fix -- appended is > the updated version of the patch I last posted. It uses the bio_list_lock > to protect the dio->waiter field, which finished_one_bio sets back > to NULL after it has issued the wakeup; and the code that waits for > i/o to drain out checks the dio->waiter field instead of bio_count. > This might not seem very obvious given the nomenclature of the > bio_list_lock, so I was holding back wondering if it could be > improved. > > Your approach looks clearer in that sense -- its pretty unambiguous > about what lock protects what fields. The only thing that bothers me (and > this is what I was trying to avoid in my patch) is the increased > use of spin_lock_irq 's (overhead of turning interrupts off and on) > instead of simple atomic inc/dec in most places. > > Thoughts ? > > Regards > Suparna ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-12-02 1:35 ` Daniel McNeil @ 2003-12-02 15:25 ` Suparna Bhattacharya 2003-12-03 23:14 ` Daniel McNeil 0 siblings, 1 reply; 52+ messages in thread From: Suparna Bhattacharya @ 2003-12-02 15:25 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio I suspect the degree to which the spin_lock_irq is costlier than atomic_inc/dec would vary across architectures - cli/sti is probably more expensive on certain archs than others. The patch I sent just kept things the way they were in terms of locking costs, assuming that those choices were thought through at that time (should check with akpm). Yours changes it by switching to spin_lock(unlock)_irq instead of atomic_dec in the normal (common) path for finished_one_bio, for both sync and async i/o. At the same time, for the sync i/o case, as you observe it takes away one atomic_dec from dio_bio_end_io. Since these probably aren't really very hot paths ... possibly the difference doesn't matter that much. I do agree that your patch makes the locking easier to follow. Regards Suparna On Mon, Dec 01, 2003 at 05:35:18PM -0800, Daniel McNeil wrote: > Suparna, > > Sorry I did not respond sooner, I was on vacation. > > Your patch should also fix the problem. I like mine with the > cleaner locking. > > I am not sure your approach has less overhead. At least > on x86, cli/sti are fairly inexpensive. The locked xchange or locked > inc/dec is what is expensive (from what I understand). > > So comparing: > > my patch: Your patch: > > dio_bio_submit() > spin_lock() atomic_inc(bio_count); > bio_count++ atomic_inc(bios_in_flight); > bios_in_flight++ > spin_unlock > > My guess is that the spin_lock/spin_unlock is faster than 2 atomic_inc's > since it is only 1 locked operation (spin_lock) verses 2 (atomic_inc's) > > finished_one_bio() (normal case) > > My patch: > spin_lock() atomic_dec_and_test(bio_count) > bio_count-- > spin_unlock() > > 1 locked instruction each, so very close -- atomic_dec_and_test() does > not disable interrupts, so it is probabably a little bit faster. > > finished_one-bio (fallback case): > > spin_lock() spin_lock() > bio_count--; dio->waiter = null > spin_unlock() spin_unlock() > > Both approaches are the same. > > dio_bio_complete() > > spin_lock() spin_lock() > bios_in_flight-- atomic_dec() > spin_unlock spin_unlock() > > My patch is faster since it removed 1 locked instruction. > > Conclusion: > > My guess would be that both approaches are close, but my patch > has less locked instructions but does disable interrupts more. > My preference is for the cleaner locking approach that is easier > to understand and modify in the future. > > Daniel > > On Tue, 2003-11-25 at 23:55, Suparna Bhattacharya wrote: > > On Tue, Nov 25, 2003 at 03:49:31PM -0800, Daniel McNeil wrote: > > > Suparna, > > > > > > Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which > > > was helping me see problems because the the freed dio was getting > > > poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is > > > very good at catching these. > > > > Ah I see - perhaps that explains why neither Janet nor I could > > recreate the problem that you were hitting so easily. So we > > should probably try running with CONFIG_DEBUG_SLAB and > > CONFIG_DEBUG_PAGEALLOC as well. > > > > > > > > I updated your AIO fallback patch plus your AIO race plus I fixed > > > the bio_count decrement fix. This patch has all three fixes and > > > it is working for me. > > > > > > I fixed the bio_count race, by changing bio_list_lock into bio_lock > > > and using that for all the bio fields. I changed bio_count and > > > bios_in_flight from atomics into int. They are now proctected by > > > the bio_lock. I fixed the race, by in finished_one_bio() by > > > leaving the bio_count at 1 until after the dio_complete() > > > and then do the bio_count decrement and wakeup holding the bio_lock. > > > > > > Take a look, give it a try, and let me know what you think. > > > > I had been trying a slightly different kind of fix -- appended is > > the updated version of the patch I last posted. It uses the bio_list_lock > > to protect the dio->waiter field, which finished_one_bio sets back > > to NULL after it has issued the wakeup; and the code that waits for > > i/o to drain out checks the dio->waiter field instead of bio_count. > > This might not seem very obvious given the nomenclature of the > > bio_list_lock, so I was holding back wondering if it could be > > improved. > > > > Your approach looks clearer in that sense -- its pretty unambiguous > > about what lock protects what fields. The only thing that bothers me (and > > this is what I was trying to avoid in my patch) is the increased > > use of spin_lock_irq 's (overhead of turning interrupts off and on) > > instead of simple atomic inc/dec in most places. > > > > Thoughts ? > > > > Regards > > Suparna > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Lab, India ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-12-02 15:25 ` Suparna Bhattacharya @ 2003-12-03 23:14 ` Daniel McNeil 2003-12-04 4:40 ` Suparna Bhattacharya 0 siblings, 1 reply; 52+ messages in thread From: Daniel McNeil @ 2003-12-03 23:14 UTC (permalink / raw) To: Suparna Bhattacharya Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Suparna, I did a quick test of your patch and my patch by running my aiocp program to write zeros to a file and to read a file. I used a 50MB file on ext2 file system on a ramdisk. The machine is a 2-proc IBM box with: model name : Intel(R) Xeon(TM) CPU 1700MHz stepping : 10 cpu MHz : 1686.033 cache size : 256 KB The write test was: time aiocp -n 32 -b 1k -s 50m -z -f DIRECT file The read test was time aiocp -n 32 -b 1k -s 50 -w -f DIRECT file I ran each test more than 10 times and here are the averages: my patch your patch aiocp write real 0.7328 real 0.7756 user 0.01425 user 0.01221 sys 0.716 sys 0.76157 aiocp read real 0.7250 real 0.7456 user 0.0144 user 0.0130 sys 0.07149 sys 0.7307 It looks like using the spin_lock instead of the atomic inc/dec is very close performance wise. The spin_lock averages a bit faster. This is not testing the fallback base, but both patches would be very similar in performance for that case. I don't have any non-intel hardware to test with. Daniel On Tue, 2003-12-02 at 07:25, Suparna Bhattacharya wrote: > I suspect the degree to which the spin_lock_irq is costlier > than atomic_inc/dec would vary across architectures - cli/sti > is probably more expensive on certain archs than others. > > The patch I sent just kept things the way they were in terms of > locking costs, assuming that those choices were thought through > at that time (should check with akpm). Yours changes it by > switching to spin_lock(unlock)_irq instead of atomic_dec in > the normal (common) path for finished_one_bio, for both sync > and async i/o. At the same time, for the sync i/o case, as > you observe it takes away one atomic_dec from dio_bio_end_io. > > Since these probably aren't really very hot paths ... possibly > the difference doesn't matter that much. I do agree that your > patch makes the locking easier to follow. > > Regards > Suparna > > On Mon, Dec 01, 2003 at 05:35:18PM -0800, Daniel McNeil wrote: > > Suparna, > > > > Sorry I did not respond sooner, I was on vacation. > > > > Your patch should also fix the problem. I like mine with the > > cleaner locking. > > > > I am not sure your approach has less overhead. At least > > on x86, cli/sti are fairly inexpensive. The locked xchange or locked > > inc/dec is what is expensive (from what I understand). > > > > So comparing: > > > > my patch: Your patch: > > > > dio_bio_submit() > > spin_lock() atomic_inc(bio_count); > > bio_count++ atomic_inc(bios_in_flight); > > bios_in_flight++ > > spin_unlock > > > > My guess is that the spin_lock/spin_unlock is faster than 2 atomic_inc's > > since it is only 1 locked operation (spin_lock) verses 2 (atomic_inc's) > > > > finished_one_bio() (normal case) > > > > My patch: > > spin_lock() atomic_dec_and_test(bio_count) > > bio_count-- > > spin_unlock() > > > > 1 locked instruction each, so very close -- atomic_dec_and_test() does > > not disable interrupts, so it is probabably a little bit faster. > > > > finished_one-bio (fallback case): > > > > spin_lock() spin_lock() > > bio_count--; dio->waiter = null > > spin_unlock() spin_unlock() > > > > Both approaches are the same. > > > > dio_bio_complete() > > > > spin_lock() spin_lock() > > bios_in_flight-- atomic_dec() > > spin_unlock spin_unlock() > > > > My patch is faster since it removed 1 locked instruction. > > > > Conclusion: > > > > My guess would be that both approaches are close, but my patch > > has less locked instructions but does disable interrupts more. > > My preference is for the cleaner locking approach that is easier > > to understand and modify in the future. > > > > Daniel > > > > On Tue, 2003-11-25 at 23:55, Suparna Bhattacharya wrote: > > > On Tue, Nov 25, 2003 at 03:49:31PM -0800, Daniel McNeil wrote: > > > > Suparna, > > > > > > > > Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which > > > > was helping me see problems because the the freed dio was getting > > > > poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is > > > > very good at catching these. > > > > > > Ah I see - perhaps that explains why neither Janet nor I could > > > recreate the problem that you were hitting so easily. So we > > > should probably try running with CONFIG_DEBUG_SLAB and > > > CONFIG_DEBUG_PAGEALLOC as well. > > > > > > > > > > > I updated your AIO fallback patch plus your AIO race plus I fixed > > > > the bio_count decrement fix. This patch has all three fixes and > > > > it is working for me. > > > > > > > > I fixed the bio_count race, by changing bio_list_lock into bio_lock > > > > and using that for all the bio fields. I changed bio_count and > > > > bios_in_flight from atomics into int. They are now proctected by > > > > the bio_lock. I fixed the race, by in finished_one_bio() by > > > > leaving the bio_count at 1 until after the dio_complete() > > > > and then do the bio_count decrement and wakeup holding the bio_lock. > > > > > > > > Take a look, give it a try, and let me know what you think. > > > > > > I had been trying a slightly different kind of fix -- appended is > > > the updated version of the patch I last posted. It uses the bio_list_lock > > > to protect the dio->waiter field, which finished_one_bio sets back > > > to NULL after it has issued the wakeup; and the code that waits for > > > i/o to drain out checks the dio->waiter field instead of bio_count. > > > This might not seem very obvious given the nomenclature of the > > > bio_list_lock, so I was holding back wondering if it could be > > > improved. > > > > > > Your approach looks clearer in that sense -- its pretty unambiguous > > > about what lock protects what fields. The only thing that bothers me (and > > > this is what I was trying to avoid in my patch) is the increased > > > use of spin_lock_irq 's (overhead of turning interrupts off and on) > > > instead of simple atomic inc/dec in most places. > > > > > > Thoughts ? > > > > > > Regards > > > Suparna > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-aio' in > > the body to majordomo@kvack.org. For more info on Linux AIO, > > see: http://www.kvack.org/aio/ > > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch 2003-12-03 23:14 ` Daniel McNeil @ 2003-12-04 4:40 ` Suparna Bhattacharya 0 siblings, 0 replies; 52+ messages in thread From: Suparna Bhattacharya @ 2003-12-04 4:40 UTC (permalink / raw) To: Daniel McNeil Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm, linux-aio Interesting :) Could it be that extra atomic_dec in dio_bio_end_io in the current code that makes the difference ? Or are spin_lock_irq and atomic_inc/dec really that close ? Would be good to know from other archs just to keep in mind in the future. As for the fallback case, performance doesn't even matter - its not a typical situation. So we don't need to bother with that. Unless someone thinks otherwise, we should go with your fix. Regards Suparna On Wed, Dec 03, 2003 at 03:14:06PM -0800, Daniel McNeil wrote: > Suparna, > > I did a quick test of your patch and my patch by running my aiocp > program to write zeros to a file and to read a file. I used > a 50MB file on ext2 file system on a ramdisk. The machine > is a 2-proc IBM box with: > > model name : Intel(R) Xeon(TM) CPU 1700MHz > stepping : 10 > cpu MHz : 1686.033 > cache size : 256 KB > > The write test was: > > time aiocp -n 32 -b 1k -s 50m -z -f DIRECT file > > The read test was > > time aiocp -n 32 -b 1k -s 50 -w -f DIRECT file > > I ran each test more than 10 times and here are the averages: > > my patch your patch > > aiocp write real 0.7328 real 0.7756 > user 0.01425 user 0.01221 > sys 0.716 sys 0.76157 > > aiocp read real 0.7250 real 0.7456 > user 0.0144 user 0.0130 > sys 0.07149 sys 0.7307 > > It looks like using the spin_lock instead of the atomic inc/dec > is very close performance wise. The spin_lock averages a bit > faster. This is not testing the fallback base, but both patches > would be very similar in performance for that case. > > I don't have any non-intel hardware to test with. > > Daniel > > > > On Tue, 2003-12-02 at 07:25, Suparna Bhattacharya wrote: > > I suspect the degree to which the spin_lock_irq is costlier > > than atomic_inc/dec would vary across architectures - cli/sti > > is probably more expensive on certain archs than others. > > > > The patch I sent just kept things the way they were in terms of > > locking costs, assuming that those choices were thought through > > at that time (should check with akpm). Yours changes it by > > switching to spin_lock(unlock)_irq instead of atomic_dec in > > the normal (common) path for finished_one_bio, for both sync > > and async i/o. At the same time, for the sync i/o case, as > > you observe it takes away one atomic_dec from dio_bio_end_io. > > > > Since these probably aren't really very hot paths ... possibly > > the difference doesn't matter that much. I do agree that your > > patch makes the locking easier to follow. > > > > Regards > > Suparna > > > > On Mon, Dec 01, 2003 at 05:35:18PM -0800, Daniel McNeil wrote: > > > Suparna, > > > > > > Sorry I did not respond sooner, I was on vacation. > > > > > > Your patch should also fix the problem. I like mine with the > > > cleaner locking. > > > > > > I am not sure your approach has less overhead. At least > > > on x86, cli/sti are fairly inexpensive. The locked xchange or locked > > > inc/dec is what is expensive (from what I understand). > > > > > > So comparing: > > > > > > my patch: Your patch: > > > > > > dio_bio_submit() > > > spin_lock() atomic_inc(bio_count); > > > bio_count++ atomic_inc(bios_in_flight); > > > bios_in_flight++ > > > spin_unlock > > > > > > My guess is that the spin_lock/spin_unlock is faster than 2 atomic_inc's > > > since it is only 1 locked operation (spin_lock) verses 2 (atomic_inc's) > > > > > > finished_one_bio() (normal case) > > > > > > My patch: > > > spin_lock() atomic_dec_and_test(bio_count) > > > bio_count-- > > > spin_unlock() > > > > > > 1 locked instruction each, so very close -- atomic_dec_and_test() does > > > not disable interrupts, so it is probabably a little bit faster. > > > > > > finished_one-bio (fallback case): > > > > > > spin_lock() spin_lock() > > > bio_count--; dio->waiter = null > > > spin_unlock() spin_unlock() > > > > > > Both approaches are the same. > > > > > > dio_bio_complete() > > > > > > spin_lock() spin_lock() > > > bios_in_flight-- atomic_dec() > > > spin_unlock spin_unlock() > > > > > > My patch is faster since it removed 1 locked instruction. > > > > > > Conclusion: > > > > > > My guess would be that both approaches are close, but my patch > > > has less locked instructions but does disable interrupts more. > > > My preference is for the cleaner locking approach that is easier > > > to understand and modify in the future. > > > > > > Daniel > > > > > > On Tue, 2003-11-25 at 23:55, Suparna Bhattacharya wrote: > > > > On Tue, Nov 25, 2003 at 03:49:31PM -0800, Daniel McNeil wrote: > > > > > Suparna, > > > > > > > > > > Yes your patch did help. I originally had CONFIG_DEBUG_SLAB=y which > > > > > was helping me see problems because the the freed dio was getting > > > > > poisoned. I also tested with CONFIG_DEBUG_PAGEALLOC=y which is > > > > > very good at catching these. > > > > > > > > Ah I see - perhaps that explains why neither Janet nor I could > > > > recreate the problem that you were hitting so easily. So we > > > > should probably try running with CONFIG_DEBUG_SLAB and > > > > CONFIG_DEBUG_PAGEALLOC as well. > > > > > > > > > > > > > > I updated your AIO fallback patch plus your AIO race plus I fixed > > > > > the bio_count decrement fix. This patch has all three fixes and > > > > > it is working for me. > > > > > > > > > > I fixed the bio_count race, by changing bio_list_lock into bio_lock > > > > > and using that for all the bio fields. I changed bio_count and > > > > > bios_in_flight from atomics into int. They are now proctected by > > > > > the bio_lock. I fixed the race, by in finished_one_bio() by > > > > > leaving the bio_count at 1 until after the dio_complete() > > > > > and then do the bio_count decrement and wakeup holding the bio_lock. > > > > > > > > > > Take a look, give it a try, and let me know what you think. > > > > > > > > I had been trying a slightly different kind of fix -- appended is > > > > the updated version of the patch I last posted. It uses the bio_list_lock > > > > to protect the dio->waiter field, which finished_one_bio sets back > > > > to NULL after it has issued the wakeup; and the code that waits for > > > > i/o to drain out checks the dio->waiter field instead of bio_count. > > > > This might not seem very obvious given the nomenclature of the > > > > bio_list_lock, so I was holding back wondering if it could be > > > > improved. > > > > > > > > Your approach looks clearer in that sense -- its pretty unambiguous > > > > about what lock protects what fields. The only thing that bothers me (and > > > > this is what I was trying to avoid in my patch) is the increased > > > > use of spin_lock_irq 's (overhead of turning interrupts off and on) > > > > instead of simple atomic inc/dec in most places. > > > > > > > > Thoughts ? > > > > > > > > Regards > > > > Suparna > > > > > > -- > > > To unsubscribe, send a message with 'unsubscribe linux-aio' in > > > the body to majordomo@kvack.org. For more info on Linux AIO, > > > see: http://www.kvack.org/aio/ > > > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> > -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Lab, India ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 (compile stats) 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton 2003-11-13 20:03 ` [PATCH] linux-2.6.0-test9-mm3_verbose-timesource-acpi-pm_A0 john stultz 2003-11-13 22:03 ` 2.6.0-test9-mm3 - AIO test results Daniel McNeil @ 2003-11-13 22:04 ` John Cherry 2003-11-14 5:07 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 19:08 ` 2.6.0-test9-mm3 Martin J. Bligh 4 siblings, 0 replies; 52+ messages in thread From: John Cherry @ 2003-11-13 22:04 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2) Warnings/Errors Summary Kernel bzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) --------------- ---------- -------- -------- -------- -------- --------- 2.6.0-test9-mm3 0w/0e 0w/0e 172w/ 0e 12w/0e 3w/0e 211w/0e 2.6.0-test9-mm2 0w/0e 0w/0e 172w/ 0e 12w/0e 3w/0e 211w/1e 2.6.0-test9-mm1 0w/0e 0w/0e 179w/ 1e 12w/0e 3w/0e 213w/1e 2.6.0-test8-mm1 0w/0e 0w/0e 183w/ 1e 13w/0e 3w/0e 223w/1e 2.6.0-test7-mm1 0w/0e 1w/0e 176w/ 1e 9w/0e 3w/0e 231w/1e 2.6.0-test6-mm4 0w/0e 1w/0e 179w/ 1e 9w/0e 3w/0e 234w/1e 2.6.0-test6-mm3 0w/0e 1w/0e 178w/ 1e 9w/0e 3w/0e 252w/2e 2.6.0-test6-mm2 0w/0e 1w/0e 179w/ 1e 9w/0e 3w/0e 252w/2e 2.6.0-test6-mm1 0w/0e 1w/0e 179w/ 1e 9w/0e 3w/0e 252w/2e Web page with links to complete details: http://developer.osdl.org/cherry/compile/ Version information for host [ cherrypit.pdx.osdl.net ] gcc: 3.2.2 patch: 2.5.4 Kernel version: 2.6.0-test9-mm3 Kernel build: Making bzImage (defconfig): 0 warnings, 0 errors Making modules (defconfig): 0 warnings, 0 errors Making bzImage (allnoconfig): 0 warnings, 0 errors Making bzImage (allyesconfig): 172 warnings, 0 errors Making modules (allyesconfig): 12 warnings, 0 errors Making bzImage (allmodconfig): 3 warnings, 0 errors Making modules (allmodconfig): 211 warnings, 0 errors Building directories: Building fs/adfs: clean Building fs/affs: clean Building fs/afs: clean Building fs/autofs: clean Building fs/autofs4: clean Building fs/befs: clean Building fs/bfs: clean Building fs/cifs: clean Building fs/coda: clean Building fs/cramfs: clean Building fs/devfs: clean Building fs/devpts: clean Building fs/efs: clean Building fs/exportfs: clean Building fs/ext2: clean Building fs/ext3: clean Building fs/fat: clean Building fs/freevxfs: clean Building fs/hfs: clean Building fs/hpfs: clean Building fs/hugetlbfs: clean Building fs/intermezzo: clean Building fs/isofs: clean Building fs/jbd: clean Building fs/jffs: clean Building fs/jffs2: clean Building fs/jfs: clean Building fs/lockd: clean Building fs/minix: clean Building fs/msdos: clean Building fs/ncpfs: clean Building fs/nfs: clean Building fs/nfsd: clean Building fs/nls: clean Building fs/ntfs: clean Building fs/partitions: clean Building fs/proc: clean Building fs/qnx4: clean Building fs/ramfs: clean Building fs/reiserfs: clean Building fs/romfs: clean Building fs/smbfs: clean Building fs/sysfs: clean Building fs/sysv: clean Building fs/udf: clean Building fs/ufs: clean Building fs/vfat: clean Building fs/xfs: clean Building drivers/i2c: clean Building drivers/net: 31 warnings, 0 errors Building drivers/media: 1 warnings, 0 errors Building drivers/base: clean Building drivers/pci: clean Building drivers/eisa: clean Building drivers/isdn: clean Building drivers/char: 1 warnings, 0 errors Building drivers/acpi: clean Building drivers/serial: 1 warnings, 0 errors Building drivers/fc4: clean Building drivers/parport: clean Building drivers/mtd: 23 warnings, 0 errors Building drivers/usb: clean Building drivers/block: 1 warnings, 0 errors Building drivers/pcmcia: 3 warnings, 0 errors Building drivers/input: clean Building drivers/atm: clean Building drivers/ide: 30 warnings, 0 errors Building drivers/pnp: clean Building drivers/oprofile: clean Building drivers/ieee1394: clean Building drivers/cdrom: 3 warnings, 0 errors Building drivers/md: clean Building drivers/message: 1 warnings, 0 errors Building drivers/cpufreq: clean Building drivers/sbus: clean Building drivers/bluetooth: clean Building drivers/telephony: 5 warnings, 0 errors Building drivers/zorro: clean Building drivers/acorn: clean Building drivers/tc: clean Building drivers/mca: clean Building drivers/nubus: clean Building drivers/misc: clean Building drivers/dio: clean Building drivers/scsi/aacraid: clean Building drivers/scsi/aic7xxx: clean Building drivers/scsi/pcmcia: 4 warnings, 0 errors Building drivers/scsi/sym53c8xx_2: clean Building drivers/video/aty: 3 warnings, 0 errors Building drivers/video/console: 2 warnings, 0 errors Building drivers/video/i810: clean Building drivers/video/logo: clean Building drivers/video/matrox: 5 warnings, 0 errors Building drivers/video/riva: clean Building drivers/video/sis: 1 warnings, 0 errors Building sound/core: clean Building sound/drivers: clean Building sound/i2c: clean Building sound/isa: 3 warnings, 0 errors Building sound/oss: 33 warnings, 0 errors Building sound/pci: clean Building sound/pcmcia: clean Building sound/synth: clean Building sound/usb: clean Building arch/i386: clean Building crypto: clean Building lib: clean Building net: 9 warnings, 0 errors Building security: clean Building sound: clean Building usr: clean Building fs: clean Building drivers/video: 8 warnings, 0 errors Building drivers/scsi: 44 warnings, 0 errors Building drivers/net: 0 warnings, 1 errors Error Summary (individual module builds): drivers/net: 0 warnings, 1 errors Warning Summary (individual module builds): drivers/block: 1 warnings, 0 errors drivers/cdrom: 3 warnings, 0 errors drivers/char: 1 warnings, 0 errors drivers/ide: 30 warnings, 0 errors drivers/media: 1 warnings, 0 errors drivers/message: 1 warnings, 0 errors drivers/mtd: 23 warnings, 0 errors drivers/net: 31 warnings, 0 errors drivers/pcmcia: 3 warnings, 0 errors drivers/scsi/pcmcia: 4 warnings, 0 errors drivers/scsi: 44 warnings, 0 errors drivers/serial: 1 warnings, 0 errors drivers/telephony: 5 warnings, 0 errors drivers/video/aty: 3 warnings, 0 errors drivers/video/console: 2 warnings, 0 errors drivers/video/matrox: 5 warnings, 0 errors drivers/video/sis: 1 warnings, 0 errors drivers/video: 8 warnings, 0 errors net: 9 warnings, 0 errors sound/isa: 3 warnings, 0 errors sound/oss: 33 warnings, 0 errors Error List: make[1]: [arch/i386/boot/bzImage] Error 1 (ignored) make[2]: [drivers/net/wan/wanxlfw.inc] Error 127 (ignored) Warning List: arch/i386/kernel/cpu/cpufreq/powernow-k8.c:38:2: warning: #warning this driver has not been tested on a preempt system arch/i386/kernel/cpu/cpufreq/powernow-k8.c:938:2: warning: #warning pol->policy is in undefined state here drivers/cdrom/aztcd.c:379: warning: `pa_ok' defined but not used drivers/cdrom/isp16.c:124: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/cdrom/mcdx.h:180:2: warning: #warning You have not edited mcdx.h drivers/cdrom/mcdx.h:181:2: warning: #warning Perhaps irq and i/o settings are wrong. drivers/cdrom/sjcd.c:1700: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/char/applicom.c:522:2: warning: #warning "Je suis stupide. DW. - copy*user in cli" drivers/char/applicom.c:67: warning: `applicom_pci_tbl' defined but not used drivers/char/watchdog/alim1535_wdt.c:320: warning: `ali_pci_tbl' defined but not used drivers/ide/ide-probe.c:1326: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/ide-probe.c:1353: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/ide/ide-tape.c:6213: warning: duplicate `const' drivers/ide/ide.c:2470: warning: implicit declaration of function `pnpide_init' drivers/ide/legacy/ide-cs.c:365: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/legacy/ide-cs.c:411: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/ide/pci/aec62xx.c:533: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/alim15x3.c:871: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/amd74xx.c:451: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/cmd64x.c:755: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/cs5520.c:294: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/cs5530.c:416: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/cy82c693.c:437: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/hpt34x.c:334: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/hpt366.c:1223: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/ns87415.c:228: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/opti621.c:364: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/pdc202xx_new.c:631: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/pdc202xx_old.c:925: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/piix.c:746: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/rz1000.c:65: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/sc1200.c:557: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/serverworks.c:804: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/siimage.c:1174: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/sis5513.c:956: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/slc90e66.c:376: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/triflex.c:227: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/trm290.c:378: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/ide/pci/trm290.c:406: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/ide/pci/via82cxxx.c:618: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/input/gameport/ns558.c:121: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/input/gameport/ns558.c:80: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/media/common/saa7146_vbi.c:6: warning: `vbi_workaround' defined but not used drivers/media/video/zoran_card.c:149: warning: `zr36067_pci_tbl' defined but not used drivers/message/fusion/mptscsih.c:6922: warning: `mptscsih_setup' defined but not used drivers/message/i2o/i2o_block.c:1506: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/mtd/chips/amd_flash.c:783: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/mtd/chips/cfi_cmdset_0001.c:381: warning: unsigned int format, different type arg (arg 2) drivers/mtd/chips/cfi_cmdset_0001.c:965: warning: unsigned int format, different type arg (arg 2) drivers/mtd/chips/cfi_cmdset_0002.c:1157: warning: unsigned int format, different type arg (arg 4) drivers/mtd/chips/cfi_cmdset_0002.c:513: warning: unsigned int format, different type arg (arg 4) drivers/mtd/chips/cfi_cmdset_0002.c:651: warning: unsigned int format, different type arg (arg 4) drivers/mtd/chips/cfi_cmdset_0002.c:977: warning: unsigned int format, different type arg (arg 4) drivers/mtd/chips/cfi_cmdset_0020.c:1139: warning: unsigned int format, different type arg (arg 3) drivers/mtd/chips/cfi_cmdset_0020.c:1288: warning: unsigned int format, different type arg (arg 3) drivers/mtd/chips/cfi_cmdset_0020.c:493: warning: unsigned int format, different type arg (arg 3) drivers/mtd/chips/cfi_cmdset_0020.c:853: warning: unsigned int format, different type arg (arg 3) drivers/mtd/chips/sharp.c:157: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/mtd/cmdlinepart.c:344: warning: `mtdpart_setup' defined but not used drivers/mtd/devices/doc2000.c:567: warning: assignment from incompatible pointer type drivers/mtd/devices/doc2000.c:568: warning: assignment from incompatible pointer type drivers/mtd/devices/doc2001.c:376: warning: assignment from incompatible pointer type drivers/mtd/devices/doc2001.c:377: warning: assignment from incompatible pointer type drivers/mtd/nftlcore.c:354: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/mtd/nftlcore.c:358: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/mtd/nftlcore.c:363: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/mtd/nftlcore.c:632: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/mtd/nftlcore.c:696: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/mtd/nftlmount.c:220: warning: passing arg 7 of pointer to function makes pointer from integer without a cast drivers/net/3c515.c:529: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/acenic.c:135: warning: `acenic_pci_tbl' defined but not used drivers/net/arcnet/arc-rimi.c:319: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/arcnet/com20020-isa.c:152: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/arcnet/com20020-pci.c:71: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/arcnet/com90io.c:385: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/arcnet/com90xx.c:146: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/arcnet/com90xx.c:412: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/arcnet/com90xx.c:609: warning: `dev_alloc' is deprecated (declared at include/linux/netdevice.h:525) drivers/net/dgrs.c:124: warning: `dgrs_pci_tbl' defined but not used drivers/net/eepro.c:575: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/ewrk3.c:1291: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/ewrk3.c:1335: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/hp100.c:288: warning: `hp100_pci_tbl' defined but not used drivers/net/hp100.c:385: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/hp100.c:432: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/hp100.c:463: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/hp100.c:471: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/sk98lin/skaddr.c:1092: warning: `ReturnCode' might be used uninitialized in this function drivers/net/sk98lin/skaddr.c:1624: warning: `ReturnCode' might be used uninitialized in this function drivers/net/skfp/skfddi.c:185: warning: `skfddi_pci_tbl' defined but not used drivers/net/tokenring/smctr.c:3494: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/net/tokenring/smctr.c:733: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/net/tulip/winbond-840.c:149: warning: `version' defined but not used drivers/net/wan/cycx_drv.c:430: warning: long unsigned int format, u32 arg (arg 2) drivers/net/wan/farsync.c:1316: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/net/wan/farsync.c:1329: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/net/wan/hostess_sv11.c:125: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/net/wan/hostess_sv11.c:157: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/net/wan/lmc/lmc_main.c:1063: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/net/wan/lmc/lmc_main.c:1184: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/net/wan/lmc/lmc_main.c:1355: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/net/wan/pc300_drv.c:3168: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/net/wan/pc300_drv.c:3204: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/net/wan/sbni.c:308: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/pcmcia/i82365.c:680: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/pcmcia/i82365.c:817: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/pcmcia/tcic.c:340: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:1003: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:1008: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:700: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:704: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:708: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:712: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:716: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:720: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:973: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:988: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:993: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/BusLogic.c:998: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/NCR5380.c:396: warning: `phases' defined but not used drivers/scsi/NCR5380.c:699: warning: `NCR5380_probe_irq' defined but not used drivers/scsi/NCR5380.c:756: warning: `NCR5380_print_options' defined but not used drivers/scsi/NCR53c406a.c:611: warning: `NCR53c406a_setup' defined but not used drivers/scsi/NCR53c406a.c:660: warning: initialization from incompatible pointer type drivers/scsi/NCR53c406a.c:669: warning: `wait_intr' defined but not used drivers/scsi/advansys.c:10006: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/advansys.c:4622: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/aha152x.c:396: warning: `id_table' defined but not used drivers/scsi/aha152x.c:793: warning: `aha152x_setup' defined but not used drivers/scsi/aha152x.c:852: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/aha152x.c:870: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/atp870u.c:2350: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/atp870u.c:2422: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/cpqfcTSinit.c:1583: warning: unused variable `timeout' drivers/scsi/cpqfcTSinit.c:1584: warning: unused variable `retries' drivers/scsi/cpqfcTSinit.c:1585: warning: unused variable `scsi_cdb' drivers/scsi/cpqfcTSinit.c:471: warning: `my_ioctl_done' defined but not used drivers/scsi/dtc.c:187: warning: `dtc_setup' defined but not used drivers/scsi/eata_pio.c:596: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/fd_mcs.c:300: warning: `fd_mcs_setup' defined but not used drivers/scsi/fd_mcs.c:311: warning: initialization from incompatible pointer type drivers/scsi/fd_mcs.h:27: warning: `fd_mcs_command' declared `static' but never defined drivers/scsi/fdomain.c:763: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/g_NCR5380.c:926: warning: `id_table' defined but not used drivers/scsi/gdth.c:881: warning: `gdthtable' defined but not used drivers/scsi/inia100.h:70: warning: `inia100_detect' declared `static' but never defined drivers/scsi/inia100.h:71: warning: `inia100_release' declared `static' but never defined drivers/scsi/inia100.h:72: warning: `inia100_queue' declared `static' but never defined drivers/scsi/inia100.h:73: warning: `inia100_abort' declared `static' but never defined drivers/scsi/inia100.h:74: warning: `inia100_device_reset' declared `static' but never defined drivers/scsi/inia100.h:75: warning: `inia100_bus_reset' declared `static' but never defined drivers/scsi/libata-core.c:2133: warning: `ata_qc_push' defined but not used drivers/scsi/psi240i.c:713: warning: initialization from incompatible pointer type drivers/scsi/psi240i.c:714: warning: initialization from incompatible pointer type drivers/scsi/sym53c416.c:627: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/sym53c416.c:715: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/scsi/wd7000.c:1611: warning: `wd7000_abort' defined but not used drivers/serial/8250.c:693: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/telephony/ixj.c:7737: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/telephony/ixj.c:7799: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/telephony/ixj.c:7835: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) drivers/telephony/ixj.h:41: warning: `ixj_h_rcsid' defined but not used drivers/usb/class/usb-midi.h:150: warning: `usb_midi_ids' defined but not used drivers/video/aty/aty128fb.c:2335: warning: `aty128fb_exit' defined but not used drivers/video/aty/aty128fb.c:254: warning: `mode' defined but not used drivers/video/aty/aty128fb.c:256: warning: `nomtrr' defined but not used drivers/video/console/mdacon.c:374: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) drivers/video/console/mdacon.c:384: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) drivers/video/hgafb.c:452: warning: `hgafb_fillrect' defined but not used drivers/video/hgafb.c:472: warning: `hgafb_copyarea' defined but not used drivers/video/hgafb.c:502: warning: `hgafb_imageblit' defined but not used drivers/video/imsttfb.c:1089: warning: `imsttfb_load_cursor_image' defined but not used drivers/video/imsttfb.c:1159: warning: `imstt_set_cursor' defined but not used drivers/video/matrox/matroxfb_base.c:1250: warning: `inverse' defined but not used drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const' drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const' drivers/video/matrox/matroxfb_maven.c:347: warning: duplicate `const' drivers/video/matrox/matroxfb_maven.c:348: warning: duplicate `const' drivers/video/sis/sis_main.c:622: warning: unused variable `reg' drivers/video/tdfxfb.c:1005: warning: `tdfxfb_cursor' defined but not used drivers/video/tdfxfb.c:198: warning: `inverse' defined but not used drivers/video/tdfxfb.c:199: warning: `mode_option' defined but not used drivers/video/tridentfb.c:455: warning: `tridentfb_fillrect' defined but not used drivers/video/tridentfb.c:473: warning: `tridentfb_copyarea' defined but not used include/linux/ixjuser.h:45: warning: `ixjuser_h_rcsid' defined but not used include/linux/mca-legacy.h:12:2: warning: #warning "MCA legacy - please move your driver to the new sysfs api" net/decnet/dn_nsp_in.c:805: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/decnet/dn_route.c:639: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv4/ipcomp.c:189: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv4/ipcomp.c:72: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv6/ipcomp6.c:174: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv6/ipcomp6.c:61: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv6/netfilter/ip6_tables.c:349: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/ipv6/netfilter/ip6table_mangle.c:162: warning: `skb_linearize' is deprecated (declared at include/linux/skbuff.h:1136) net/wanrouter/wanmain.c:729: warning: `dev_get' is deprecated (declared at include/linux/netdevice.h:514) sound/isa/opti9xx/opti92x-ad1848.c:1670: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/isa/opti9xx/opti92x-ad1848.c:1686: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/isa/opti9xx/opti92x-ad1848.c:314: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/ad1848.c:1580: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/ad1848.c:2530: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/ad1848.c:2967: warning: `id_table' defined but not used sound/oss/cmpci.c:1465: warning: unused variable `s' sound/oss/cmpci.c:2865: warning: `cmpci_pci_tbl' defined but not used sound/oss/cs4232.c:141: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/cs4232.c:193: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/gus_card.c:76: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/gus_card.c:78: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/gus_card.c:93: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/gus_card.c:94: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/mad16.c:322: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/maui.c:307: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/mpu401.c:1217: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/msnd.c:74: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:482) sound/oss/msnd.c:95: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:494) sound/oss/msnd_pinnacle.c:1123: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/msnd_pinnacle.c:1811: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/opl3sa.c:114: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/opl3sa.c:122: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/pss.c:1004: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/pss.c:191: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/pss.c:640: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/pss.c:710: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sb_common.c:1224: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sb_common.c:523: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sgalaxy.c:89: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sgalaxy.c:97: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sscape.c:1113: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sscape.c:1132: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sscape.c:1137: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/sscape.c:737: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/trix.c:147: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/trix.c:292: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/trix.c:85: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/wavfront.c:2426: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) sound/oss/wf_midi.c:788: warning: `check_region' is deprecated (declared at include/linux/ioport.h:119) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton ` (2 preceding siblings ...) 2003-11-13 22:04 ` 2.6.0-test9-mm3 (compile stats) John Cherry @ 2003-11-14 5:07 ` Martin J. Bligh 2003-11-14 20:57 ` 2.6.0-test9-mm3 Zwane Mwaikambo 2003-11-14 19:08 ` 2.6.0-test9-mm3 Martin J. Bligh 4 siblings, 1 reply; 52+ messages in thread From: Martin J. Bligh @ 2003-11-14 5:07 UTC (permalink / raw) To: Andrew Morton, linux-kernel, linux-mm > - Several ext2 and ext3 allocator fixes. These need serious testing on big > SMP. Survives kernbench and SDET on ext2 at least on 16-way. I'll try ext3 later. M. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 5:07 ` 2.6.0-test9-mm3 Martin J. Bligh @ 2003-11-14 20:57 ` Zwane Mwaikambo 2003-11-14 21:57 ` 2.6.0-test9-mm3 Martin J. Bligh 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-14 20:57 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm On Thu, 13 Nov 2003, Martin J. Bligh wrote: > > - Several ext2 and ext3 allocator fixes. These need serious testing on big > > SMP. > > Survives kernbench and SDET on ext2 at least on 16-way. I'll try ext3 > later. It's actually triple faulting my laptop (K6 family=5 model=8 step=12) when i have CONFIG_X86_4G enabled and try and run X11. The same kernel is fine on all my other test boxes. Any hints? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 20:57 ` 2.6.0-test9-mm3 Zwane Mwaikambo @ 2003-11-14 21:57 ` Martin J. Bligh 2003-11-14 21:37 ` 2.6.0-test9-mm3 Zwane Mwaikambo 2003-11-14 21:47 ` 2.6.0-test9-mm3 Linus Torvalds 0 siblings, 2 replies; 52+ messages in thread From: Martin J. Bligh @ 2003-11-14 21:57 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Andrew Morton, linux-kernel, linux-mm >> > - Several ext2 and ext3 allocator fixes. These need serious testing on big >> > SMP. >> >> Survives kernbench and SDET on ext2 at least on 16-way. I'll try ext3 >> later. > > It's actually triple faulting my laptop (K6 family=5 model=8 step=12) when > i have CONFIG_X86_4G enabled and try and run X11. The same kernel is fine > on all my other test boxes. Any hints? Linus had some debug thing for triple faults, a few months ago, IIRC ... probably in the archives somewhere ... M. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 21:57 ` 2.6.0-test9-mm3 Martin J. Bligh @ 2003-11-14 21:37 ` Zwane Mwaikambo 2003-11-14 21:47 ` 2.6.0-test9-mm3 Linus Torvalds 1 sibling, 0 replies; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-14 21:37 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm On Fri, 14 Nov 2003, Martin J. Bligh wrote: > >> > - Several ext2 and ext3 allocator fixes. These need serious testing on big > >> > SMP. > >> > >> Survives kernbench and SDET on ext2 at least on 16-way. I'll try ext3 > >> later. > > > > It's actually triple faulting my laptop (K6 family=5 model=8 step=12) when > > i have CONFIG_X86_4G enabled and try and run X11. The same kernel is fine > > on all my other test boxes. Any hints? > > Linus had some debug thing for triple faults, a few months ago, IIRC ... > probably in the archives somewhere ... It should all be in the kernel right now; arch/i386/kernel/doublefault.c but i think i may be a bit low on luck =) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 21:57 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 21:37 ` 2.6.0-test9-mm3 Zwane Mwaikambo @ 2003-11-14 21:47 ` Linus Torvalds 2003-11-15 0:55 ` 2.6.0-test9-mm3 Zwane Mwaikambo 1 sibling, 1 reply; 52+ messages in thread From: Linus Torvalds @ 2003-11-14 21:47 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Zwane Mwaikambo, Andrew Morton, linux-kernel, linux-mm On Fri, 14 Nov 2003, Martin J. Bligh wrote: > > Linus had some debug thing for triple faults, a few months ago, IIRC ... > probably in the archives somewhere ... Triple faults you can't debug, they raise a line outside the CPU, and normal PC hardware will cause that to just trigger a reboot. But double faults do get caught, and that debugging stuff actually is in the standard kernel. It won't give _nearly_ as good a debug report as a "normal" oops, since I didn't want the double-fault handler to touch anything even remotely unsafe, but it often gives a good hint about what might be wrong. Certainly better than triple-faulting did (which we still do for _catastrophic_ corruption, eg totally munged kernel page tables etc - it's just very hard to avoid once you get corrupted enough). Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 21:47 ` 2.6.0-test9-mm3 Linus Torvalds @ 2003-11-15 0:55 ` Zwane Mwaikambo 2003-11-15 19:34 ` [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-15 0:55 UTC (permalink / raw) To: Linus Torvalds; +Cc: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm On Fri, 14 Nov 2003, Linus Torvalds wrote: > Triple faults you can't debug, they raise a line outside the CPU, and > normal PC hardware will cause that to just trigger a reboot. > > But double faults do get caught, and that debugging stuff actually is in > the standard kernel. It won't give _nearly_ as good a debug report as a > "normal" oops, since I didn't want the double-fault handler to touch > anything even remotely unsafe, but it often gives a good hint about what > might be wrong. Certainly better than triple-faulting did (which we still > do for _catastrophic_ corruption, eg totally munged kernel page tables etc > - it's just very hard to avoid once you get corrupted enough). "Catastrophic" seems to be rather apt here. 2.6.0-test8-mm1 produced the following, i'm still doing a binary search. Unable to handle kernel paging request at virtual address 00002000 printing eip: 00007341 *pde = 00000000 Oops: 0004 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 0 EIP: c000:[<00007341>] Not tainted VLI EFLAGS: 00033246 EIP is at 0x7341 eax: 32454256 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00002000 ebp: 00000fd6 esp: 08763f24 ds: 0000 es: 0000 ss: 0068 Process X (pid: 939, threadinfo=08762000 task=0890b330) Stack: 00000fcb 00000100 00000000 0000c000 00000000 00000000 00000000 00000000 00000005 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff Call Trace: Code: Bad EIP value. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-15 0:55 ` 2.6.0-test9-mm3 Zwane Mwaikambo @ 2003-11-15 19:34 ` Zwane Mwaikambo 2003-11-15 19:52 ` Zwane Mwaikambo 2003-11-17 21:46 ` Zwane Mwaikambo 0 siblings, 2 replies; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-15 19:34 UTC (permalink / raw) To: Ingo Molnar Cc: Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins The 4G/4G page fault handling path doesn't appear to handle faults happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in kernel test. However i'm still debugging the X11 triple fault in test9-mm3 Unable to handle kernel paging request at virtual address 00002000 printing eip: 00007341 *pde = 00000000 Oops: 0004 [#1] SMP DEBUG_PAGEALLOC CPU: 0 EIP: c000:[<00007341>] Not tainted VLI EFLAGS: 00033246 EIP is at 0x7341 eax: 32454256 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00002000 ebp: 00000fd6 esp: 087bbf24 ds: 0000 es: 0000 ss: 0068 Process X (pid: 939, threadinfo=087ba000 task=0891c690) Stack: 00000fcb 00000100 00000000 0000c000 00000000 00000000 00000000 00000000 00000005 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff Call Trace: Index: linux-2.6.0-test9-mm3/arch/i386/mm/fault.c =================================================================== RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/mm/fault.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 fault.c --- linux-2.6.0-test9-mm3/arch/i386/mm/fault.c 13 Nov 2003 08:07:17 -0000 1.1.1.1 +++ linux-2.6.0-test9-mm3/arch/i386/mm/fault.c 15 Nov 2003 19:08:34 -0000 @@ -264,7 +264,9 @@ asmlinkage void do_page_fault(struct pt_ if (error_code & 3) goto bad_area_nosemaphore; - goto vmalloc_fault; + /* If it's vm86 fall through */ + if (!(error_code & 4)) + goto vmalloc_fault; } #else if (unlikely(address >= TASK_SIZE)) { ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-15 19:34 ` [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Zwane Mwaikambo @ 2003-11-15 19:52 ` Zwane Mwaikambo 2003-11-17 21:46 ` Zwane Mwaikambo 1 sibling, 0 replies; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-15 19:52 UTC (permalink / raw) To: Ingo Molnar Cc: Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Sat, 15 Nov 2003, Zwane Mwaikambo wrote: > The 4G/4G page fault handling path doesn't appear to handle faults > happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in > kernel test. Perhaps this would be more desirable? Index: linux-2.6.0-test9-mm3/arch/i386/mm/fault.c =================================================================== RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/mm/fault.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 fault.c --- linux-2.6.0-test9-mm3/arch/i386/mm/fault.c 13 Nov 2003 08:07:17 -0000 1.1.1.1 +++ linux-2.6.0-test9-mm3/arch/i386/mm/fault.c 15 Nov 2003 19:40:17 -0000 @@ -264,7 +264,9 @@ asmlinkage void do_page_fault(struct pt_ if (error_code & 3) goto bad_area_nosemaphore; - goto vmalloc_fault; + /* If it's vm86 fall through */ + if (!(regs->eflags & VM_MASK)) + goto vmalloc_fault; } #else if (unlikely(address >= TASK_SIZE)) { ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-15 19:34 ` [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Zwane Mwaikambo 2003-11-15 19:52 ` Zwane Mwaikambo @ 2003-11-17 21:46 ` Zwane Mwaikambo 2003-11-17 22:42 ` Linus Torvalds 1 sibling, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-17 21:46 UTC (permalink / raw) To: Ingo Molnar Cc: Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Sat, 15 Nov 2003, Zwane Mwaikambo wrote: > The 4G/4G page fault handling path doesn't appear to handle faults > happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in > kernel test. > > However i'm still debugging the X11 triple fault in test9-mm3 I've managed to `fix` the triple fault (see further below for the patch in all it's glory). Unfortunately i have been unable to come up with a simpler workaround which is fewer instructions and easier to debug. I have tried the following; mb()/barrier() flush_tlb_all() wbinvd() outb(0x80,0x00) local_irq_save(flags); local_irq_enable(); loop(); local_irq_restore(flags); long_loop() What i do know is that in the following code; __asm__ __volatile__( "xorl %%eax,%%eax; movl %%eax,%%fs; movl %%eax,%%gs\n\t" "movl %0,%%esp\n\t" "movl %1,%%ebp\n\t" "jmp resume_userspace" : /* no outputs */ :"r" (&info->regs), "r" (tsk->thread_info) : "ax"); It does get to resume_userspace as putting a $0 into %ebp will oops in __switch_to And here is the current 'workaround'. Any hints? Index: arch/i386/kernel/vm86.c =================================================================== RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/kernel/vm86.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 vm86.c --- arch/i386/kernel/vm86.c 13 Nov 2003 08:07:17 -0000 1.1.1.1 +++ arch/i386/kernel/vm86.c 17 Nov 2003 21:45:13 -0000 @@ -312,6 +311,8 @@ static void do_sys_vm86(struct kernel_vm tsk->thread.screen_bitmap = info->screen_bitmap; if (info->flags & VM86_SCREEN_BITMAP) mark_screen_rdonly(tsk); + + printk("ooh la la\n"); __asm__ __volatile__( "xorl %%eax,%%eax; movl %%eax,%%fs; movl %%eax,%%gs\n\t" "movl %0,%%esp\n\t" ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-17 21:46 ` Zwane Mwaikambo @ 2003-11-17 22:42 ` Linus Torvalds 2003-11-17 23:01 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Linus Torvalds @ 2003-11-17 22:42 UTC (permalink / raw) To: Zwane Mwaikambo Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Mon, 17 Nov 2003, Zwane Mwaikambo wrote: > > I've managed to `fix` the triple fault (see further below for the patch > in all it's glory). What's the generated assembly language for this function with and without the "fix"? If adding that printk fixes a triple fault, the issue is not likely to be the printk itself as much as the difference in code that the compiler generates - stack frame, memory re-ordering etc... Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-17 22:42 ` Linus Torvalds @ 2003-11-17 23:01 ` Zwane Mwaikambo 2003-11-17 23:14 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-17 23:01 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Mon, 17 Nov 2003, Linus Torvalds wrote: > What's the generated assembly language for this function with and without > the "fix"? > > If adding that printk fixes a triple fault, the issue is not likely to be > the printk itself as much as the difference in code that the compiler > generates - stack frame, memory re-ordering etc... This would be my 'trusty' gcc 3.2.2 from RedHat 9 (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) With the fix: 0x0210e860 <do_sys_vm86+0>: push %edi 0x0210e861 <do_sys_vm86+1>: mov $0xffffe000,%eax 0x0210e866 <do_sys_vm86+6>: push %esi 0x0210e867 <do_sys_vm86+7>: and %esp,%eax 0x0210e869 <do_sys_vm86+9>: push %ebx 0x0210e86a <do_sys_vm86+10>: mov 0x10(%esp,1),%edi 0x0210e86e <do_sys_vm86+14>: mov 0x14(%esp,1),%esi 0x0210e872 <do_sys_vm86+18>: movl $0x0,0x1c(%edi) 0x0210e879 <do_sys_vm86+25>: movl $0x0,0x20(%edi) 0x0210e880 <do_sys_vm86+32>: mov (%eax),%edx 0x0210e882 <do_sys_vm86+34>: mov 0x30(%edi),%eax 0x0210e885 <do_sys_vm86+37>: mov %eax,0x5b8(%edx) 0x0210e88b <do_sys_vm86+43>: mov 0x30(%edi),%edx 0x0210e88e <do_sys_vm86+46>: mov 0xbc(%edi),%eax 0x0210e894 <do_sys_vm86+52>: and $0xdd5,%edx 0x0210e89a <do_sys_vm86+58>: mov %edx,0x30(%edi) 0x0210e89d <do_sys_vm86+61>: mov 0x30(%eax),%eax 0x0210e8a0 <do_sys_vm86+64>: and $0xfffff22a,%eax 0x0210e8a5 <do_sys_vm86+69>: or %eax,%edx 0x0210e8a7 <do_sys_vm86+71>: mov 0x54(%edi),%eax 0x0210e8aa <do_sys_vm86+74>: or $0x20000,%edx 0x0210e8b0 <do_sys_vm86+80>: cmp $0x3,%eax 0x0210e8b3 <do_sys_vm86+83>: mov %edx,0x30(%edi) 0x0210e8b6 <do_sys_vm86+86>: je 0x210e9f0 <do_sys_vm86+400> 0x0210e8bc <do_sys_vm86+92>: cmp $0x3,%eax 0x0210e8bf <do_sys_vm86+95>: ja 0x210e9d5 <do_sys_vm86+373> 0x0210e8c5 <do_sys_vm86+101>: cmp $0x2,%eax 0x0210e8c8 <do_sys_vm86+104>: je 0x210e9c6 <do_sys_vm86+358> 0x0210e8ce <do_sys_vm86+110>: movl $0x247000,0x5bc(%esi) 0x0210e8d8 <do_sys_vm86+120>: mov 0xbc(%edi),%eax 0x0210e8de <do_sys_vm86+126>: movl $0x0,0x18(%eax) 0x0210e8e5 <do_sys_vm86+133>: mov 0x360(%esi),%eax 0x0210e8eb <do_sys_vm86+139>: mov %eax,0x5c0(%esi) 0x0210e8f1 <do_sys_vm86+145>: movl %fs,0x5c4(%esi) 0x0210e8f7 <do_sys_vm86+151>: movl %gs,0x5c8(%esi) 0x0210e8fd <do_sys_vm86+157>: mov $0xffffe000,%ebx 0x0210e902 <do_sys_vm86+162>: and %esp,%ebx 0x0210e904 <do_sys_vm86+164>: mov 0x14(%ebx),%eax 0x0210e907 <do_sys_vm86+167>: inc %eax 0x0210e908 <do_sys_vm86+168>: mov %eax,0x14(%ebx) 0x0210e90b <do_sys_vm86+171>: mov 0x10(%ebx),%eax 0x0210e90e <do_sys_vm86+174>: mov 0x4(%esi),%edx 0x0210e911 <do_sys_vm86+177>: shl $0x9,%eax 0x0210e914 <do_sys_vm86+180>: lea 0x26ff000(%eax),%ecx 0x0210e91a <do_sys_vm86+186>: lea 0x4c(%edi),%eax 0x0210e91d <do_sys_vm86+189>: mov %eax,0x360(%esi) 0x0210e923 <do_sys_vm86+195>: sub 0x1c(%edx),%eax 0x0210e926 <do_sys_vm86+198>: add 0x20(%edx),%eax 0x0210e929 <do_sys_vm86+201>: mov %eax,0x4(%ecx) 0x0210e92c <do_sys_vm86+204>: mov 0x25fe52c,%eax 0x0210e931 <do_sys_vm86+209>: test $0x800,%eax 0x0210e936 <do_sys_vm86+214>: je 0x210e942 <do_sys_vm86+226> 0x0210e938 <do_sys_vm86+216>: movl $0x0,0x364(%esi) 0x0210e942 <do_sys_vm86+226>: lea 0x340(%esi),%edx 0x0210e948 <do_sys_vm86+232>: mov 0x20(%edx),%eax 0x0210e94b <do_sys_vm86+235>: mov %eax,0x4(%ecx) 0x0210e94e <do_sys_vm86+238>: mov 0x10(%ecx),%ax 0x0210e952 <do_sys_vm86+242>: and $0xffff,%eax 0x0210e957 <do_sys_vm86+247>: cmp 0x24(%edx),%eax 0x0210e95a <do_sys_vm86+250>: jne 0x210e9b0 <do_sys_vm86+336> 0x0210e95c <do_sys_vm86+252>: mov 0x14(%ebx),%eax 0x0210e95f <do_sys_vm86+255>: dec %eax 0x0210e960 <do_sys_vm86+256>: mov %eax,0x14(%ebx) 0x0210e963 <do_sys_vm86+259>: mov 0x8(%ebx),%eax 0x0210e966 <do_sys_vm86+262>: and $0x8,%eax 0x0210e969 <do_sys_vm86+265>: jne 0x210e9a9 <do_sys_vm86+329> 0x0210e96b <do_sys_vm86+267>: push $0x255f121 0x0210e970 <do_sys_vm86+272>: call 0x21285a0 <printk> 0x0210e975 <do_sys_vm86+277>: mov 0x50(%edi),%eax 0x0210e978 <do_sys_vm86+280>: mov %eax,0x5b4(%esi) 0x0210e97e <do_sys_vm86+286>: pop %eax 0x0210e97f <do_sys_vm86+287>: testb $0x1,0x4c(%edi) 0x0210e983 <do_sys_vm86+291>: jne 0x210e9a0 <do_sys_vm86+320> 0x0210e985 <do_sys_vm86+293>: mov 0x4(%esi),%edx 0x0210e988 <do_sys_vm86+296>: xor %eax,%eax 0x0210e98a <do_sys_vm86+298>: mov %eax,%fs 0x0210e98c <do_sys_vm86+300>: mov %eax,%gs 0x0210e98e <do_sys_vm86+302>: mov %edi,%esp 0x0210e990 <do_sys_vm86+304>: mov %edx,%ebp 0x0210e992 <do_sys_vm86+306>: jmp 0xfffeb100 <resume_userspace> 0x0210e997 <do_sys_vm86+311>: pop %ebx 0x0210e998 <do_sys_vm86+312>: pop %esi 0x0210e999 <do_sys_vm86+313>: pop %edi 0x0210e99a <do_sys_vm86+314>: ret 0x0210e99b <do_sys_vm86+315>: nop 0x0210e99c <do_sys_vm86+316>: lea 0x0(%esi,1),%esi 0x0210e9a0 <do_sys_vm86+320>: push %esi 0x0210e9a1 <do_sys_vm86+321>: call 0x210e5b0 <mark_screen_rdonly> 0x0210e9a6 <do_sys_vm86+326>: pop %eax 0x0210e9a7 <do_sys_vm86+327>: jmp 0x210e985 <do_sys_vm86+293> 0x0210e9a9 <do_sys_vm86+329>: call 0x21222d0 <preempt_schedule> 0x0210e9ae <do_sys_vm86+334>: jmp 0x210e96b <do_sys_vm86+267> 0x0210e9b0 <do_sys_vm86+336>: mov 0x24(%edx),%ax 0x0210e9b4 <do_sys_vm86+340>: mov %ax,0x10(%ecx) 0x0210e9b8 <do_sys_vm86+344>: mov $0x174,%ecx 0x0210e9bd <do_sys_vm86+349>: mov 0x24(%edx),%eax 0x0210e9c0 <do_sys_vm86+352>: xor %edx,%edx 0x0210e9c2 <do_sys_vm86+354>: wrmsr 0x0210e9c4 <do_sys_vm86+356>: jmp 0x210e95c <do_sys_vm86+252> 0x0210e9c6 <do_sys_vm86+358>: movl $0x0,0x5bc(%esi) 0x0210e9d0 <do_sys_vm86+368>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9d5 <do_sys_vm86+373>: cmp $0x4,%eax 0x0210e9d8 <do_sys_vm86+376>: jne 0x210e8ce <do_sys_vm86+110> 0x0210e9de <do_sys_vm86+382>: movl $0x47000,0x5bc(%esi) 0x0210e9e8 <do_sys_vm86+392>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9ed <do_sys_vm86+397>: lea 0x0(%esi),%esi 0x0210e9f0 <do_sys_vm86+400>: movl $0x7000,0x5bc(%esi) 0x0210e9fa <do_sys_vm86+410>: jmp 0x210e8d8 <do_sys_vm86+120> Without the fix: 0x0210e860 <do_sys_vm86+0>: push %edi 0x0210e861 <do_sys_vm86+1>: mov $0xffffe000,%eax 0x0210e866 <do_sys_vm86+6>: push %esi 0x0210e867 <do_sys_vm86+7>: and %esp,%eax 0x0210e869 <do_sys_vm86+9>: push %ebx 0x0210e86a <do_sys_vm86+10>: mov 0x10(%esp,1),%edi 0x0210e86e <do_sys_vm86+14>: mov 0x14(%esp,1),%esi 0x0210e872 <do_sys_vm86+18>: movl $0x0,0x1c(%edi) 0x0210e879 <do_sys_vm86+25>: movl $0x0,0x20(%edi) 0x0210e880 <do_sys_vm86+32>: mov (%eax),%edx 0x0210e882 <do_sys_vm86+34>: mov 0x30(%edi),%eax 0x0210e885 <do_sys_vm86+37>: mov %eax,0x5b8(%edx) 0x0210e88b <do_sys_vm86+43>: mov 0x30(%edi),%edx 0x0210e88e <do_sys_vm86+46>: mov 0xbc(%edi),%eax 0x0210e894 <do_sys_vm86+52>: and $0xdd5,%edx 0x0210e89a <do_sys_vm86+58>: mov %edx,0x30(%edi) 0x0210e89d <do_sys_vm86+61>: mov 0x30(%eax),%eax 0x0210e8a0 <do_sys_vm86+64>: and $0xfffff22a,%eax 0x0210e8a5 <do_sys_vm86+69>: or %eax,%edx 0x0210e8a7 <do_sys_vm86+71>: mov 0x54(%edi),%eax 0x0210e8aa <do_sys_vm86+74>: or $0x20000,%edx 0x0210e8b0 <do_sys_vm86+80>: cmp $0x3,%eax 0x0210e8b3 <do_sys_vm86+83>: mov %edx,0x30(%edi) 0x0210e8b6 <do_sys_vm86+86>: je 0x210e9e0 <do_sys_vm86+384> 0x0210e8bc <do_sys_vm86+92>: cmp $0x3,%eax 0x0210e8bf <do_sys_vm86+95>: ja 0x210e9c5 <do_sys_vm86+357> 0x0210e8c5 <do_sys_vm86+101>: cmp $0x2,%eax 0x0210e8c8 <do_sys_vm86+104>: je 0x210e9b6 <do_sys_vm86+342> 0x0210e8ce <do_sys_vm86+110>: movl $0x247000,0x5bc(%esi) 0x0210e8d8 <do_sys_vm86+120>: mov 0xbc(%edi),%eax 0x0210e8de <do_sys_vm86+126>: movl $0x0,0x18(%eax) 0x0210e8e5 <do_sys_vm86+133>: mov 0x360(%esi),%eax 0x0210e8eb <do_sys_vm86+139>: mov %eax,0x5c0(%esi) 0x0210e8f1 <do_sys_vm86+145>: movl %fs,0x5c4(%esi) 0x0210e8f7 <do_sys_vm86+151>: movl %gs,0x5c8(%esi) 0x0210e8fd <do_sys_vm86+157>: mov $0xffffe000,%ebx 0x0210e902 <do_sys_vm86+162>: and %esp,%ebx 0x0210e904 <do_sys_vm86+164>: mov 0x14(%ebx),%eax 0x0210e907 <do_sys_vm86+167>: inc %eax 0x0210e908 <do_sys_vm86+168>: mov %eax,0x14(%ebx) 0x0210e90b <do_sys_vm86+171>: mov 0x10(%ebx),%eax 0x0210e90e <do_sys_vm86+174>: mov 0x4(%esi),%edx 0x0210e911 <do_sys_vm86+177>: shl $0x9,%eax 0x0210e914 <do_sys_vm86+180>: lea 0x26ff000(%eax),%ecx 0x0210e91a <do_sys_vm86+186>: lea 0x4c(%edi),%eax 0x0210e91d <do_sys_vm86+189>: mov %eax,0x360(%esi) 0x0210e923 <do_sys_vm86+195>: sub 0x1c(%edx),%eax 0x0210e926 <do_sys_vm86+198>: add 0x20(%edx),%eax 0x0210e929 <do_sys_vm86+201>: mov %eax,0x4(%ecx) 0x0210e92c <do_sys_vm86+204>: mov 0x25fe52c,%eax 0x0210e931 <do_sys_vm86+209>: test $0x800,%eax 0x0210e936 <do_sys_vm86+214>: je 0x210e942 <do_sys_vm86+226> 0x0210e938 <do_sys_vm86+216>: movl $0x0,0x364(%esi) 0x0210e942 <do_sys_vm86+226>: lea 0x340(%esi),%edx 0x0210e948 <do_sys_vm86+232>: mov 0x20(%edx),%eax 0x0210e94b <do_sys_vm86+235>: mov %eax,0x4(%ecx) 0x0210e94e <do_sys_vm86+238>: mov 0x10(%ecx),%ax 0x0210e952 <do_sys_vm86+242>: and $0xffff,%eax 0x0210e957 <do_sys_vm86+247>: cmp 0x24(%edx),%eax 0x0210e95a <do_sys_vm86+250>: jne 0x210e9a0 <do_sys_vm86+320> 0x0210e95c <do_sys_vm86+252>: mov 0x14(%ebx),%eax 0x0210e95f <do_sys_vm86+255>: dec %eax 0x0210e960 <do_sys_vm86+256>: mov %eax,0x14(%ebx) 0x0210e963 <do_sys_vm86+259>: mov 0x8(%ebx),%eax 0x0210e966 <do_sys_vm86+262>: and $0x8,%eax 0x0210e969 <do_sys_vm86+265>: jne 0x210e999 <do_sys_vm86+313> 0x0210e96b <do_sys_vm86+267>: mov 0x50(%edi),%eax 0x0210e96e <do_sys_vm86+270>: mov %eax,0x5b4(%esi) 0x0210e974 <do_sys_vm86+276>: testb $0x1,0x4c(%edi) 0x0210e978 <do_sys_vm86+280>: jne 0x210e990 <do_sys_vm86+304> 0x0210e97a <do_sys_vm86+282>: mov 0x4(%esi),%edx 0x0210e97d <do_sys_vm86+285>: xor %eax,%eax 0x0210e97f <do_sys_vm86+287>: mov %eax,%fs 0x0210e981 <do_sys_vm86+289>: mov %eax,%gs 0x0210e983 <do_sys_vm86+291>: mov %edi,%esp 0x0210e985 <do_sys_vm86+293>: mov %edx,%ebp 0x0210e987 <do_sys_vm86+295>: jmp 0xfffeb100 <resume_userspace> 0x0210e98c <do_sys_vm86+300>: pop %ebx 0x0210e98d <do_sys_vm86+301>: pop %esi 0x0210e98e <do_sys_vm86+302>: pop %edi 0x0210e98f <do_sys_vm86+303>: ret 0x0210e990 <do_sys_vm86+304>: push %esi 0x0210e991 <do_sys_vm86+305>: call 0x210e5b0 <mark_screen_rdonly> 0x0210e996 <do_sys_vm86+310>: pop %eax 0x0210e997 <do_sys_vm86+311>: jmp 0x210e97a <do_sys_vm86+282> 0x0210e999 <do_sys_vm86+313>: call 0x21222c0 <preempt_schedule> 0x0210e99e <do_sys_vm86+318>: jmp 0x210e96b <do_sys_vm86+267> 0x0210e9a0 <do_sys_vm86+320>: mov 0x24(%edx),%ax 0x0210e9a4 <do_sys_vm86+324>: mov %ax,0x10(%ecx) 0x0210e9a8 <do_sys_vm86+328>: mov $0x174,%ecx 0x0210e9ad <do_sys_vm86+333>: mov 0x24(%edx),%eax 0x0210e9b0 <do_sys_vm86+336>: xor %edx,%edx 0x0210e9b2 <do_sys_vm86+338>: wrmsr 0x0210e9b4 <do_sys_vm86+340>: jmp 0x210e95c <do_sys_vm86+252> 0x0210e9b6 <do_sys_vm86+342>: movl $0x0,0x5bc(%esi) 0x0210e9c0 <do_sys_vm86+352>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9c5 <do_sys_vm86+357>: cmp $0x4,%eax 0x0210e9c8 <do_sys_vm86+360>: jne 0x210e8ce <do_sys_vm86+110> 0x0210e9ce <do_sys_vm86+366>: movl $0x47000,0x5bc(%esi) 0x0210e9d8 <do_sys_vm86+376>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9dd <do_sys_vm86+381>: lea 0x0(%esi),%esi 0x0210e9e0 <do_sys_vm86+384>: movl $0x7000,0x5bc(%esi) 0x0210e9ea <do_sys_vm86+394>: jmp 0x210e8d8 <do_sys_vm86+120> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-17 23:01 ` Zwane Mwaikambo @ 2003-11-17 23:14 ` Zwane Mwaikambo 2003-11-18 7:21 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-17 23:14 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Mon, 17 Nov 2003, Zwane Mwaikambo wrote: > On Mon, 17 Nov 2003, Linus Torvalds wrote: > > > What's the generated assembly language for this function with and without > > the "fix"? > > > > If adding that printk fixes a triple fault, the issue is not likely to be > > the printk itself as much as the difference in code that the compiler > > generates - stack frame, memory re-ordering etc... > > This would be my 'trusty' gcc 3.2.2 from RedHat 9 > (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) A little bird told me to send diffs... But there is a lot of noise due to offsets i'm afraid. --- buggy 2003-11-17 18:09:35.302964248 -0500 +++ works 2003-11-17 18:09:47.744072912 -0500 @@ -21,11 +21,11 @@ 0x0210e8aa <do_sys_vm86+74>: or $0x20000,%edx 0x0210e8b0 <do_sys_vm86+80>: cmp $0x3,%eax 0x0210e8b3 <do_sys_vm86+83>: mov %edx,0x30(%edi) -0x0210e8b6 <do_sys_vm86+86>: je 0x210e9e0 <do_sys_vm86+384> +0x0210e8b6 <do_sys_vm86+86>: je 0x210e9f0 <do_sys_vm86+400> 0x0210e8bc <do_sys_vm86+92>: cmp $0x3,%eax -0x0210e8bf <do_sys_vm86+95>: ja 0x210e9c5 <do_sys_vm86+357> +0x0210e8bf <do_sys_vm86+95>: ja 0x210e9d5 <do_sys_vm86+373> 0x0210e8c5 <do_sys_vm86+101>: cmp $0x2,%eax -0x0210e8c8 <do_sys_vm86+104>: je 0x210e9b6 <do_sys_vm86+342> +0x0210e8c8 <do_sys_vm86+104>: je 0x210e9c6 <do_sys_vm86+358> 0x0210e8ce <do_sys_vm86+110>: movl $0x247000,0x5bc(%esi) 0x0210e8d8 <do_sys_vm86+120>: mov 0xbc(%edi),%eax 0x0210e8de <do_sys_vm86+126>: movl $0x0,0x18(%eax) @@ -57,47 +57,52 @@ 0x0210e94e <do_sys_vm86+238>: mov 0x10(%ecx),%ax 0x0210e952 <do_sys_vm86+242>: and $0xffff,%eax 0x0210e957 <do_sys_vm86+247>: cmp 0x24(%edx),%eax -0x0210e95a <do_sys_vm86+250>: jne 0x210e9a0 <do_sys_vm86+320> +0x0210e95a <do_sys_vm86+250>: jne 0x210e9b0 <do_sys_vm86+336> 0x0210e95c <do_sys_vm86+252>: mov 0x14(%ebx),%eax 0x0210e95f <do_sys_vm86+255>: dec %eax 0x0210e960 <do_sys_vm86+256>: mov %eax,0x14(%ebx) 0x0210e963 <do_sys_vm86+259>: mov 0x8(%ebx),%eax 0x0210e966 <do_sys_vm86+262>: and $0x8,%eax -0x0210e969 <do_sys_vm86+265>: jne 0x210e999 <do_sys_vm86+313> -0x0210e96b <do_sys_vm86+267>: mov 0x50(%edi),%eax -0x0210e96e <do_sys_vm86+270>: mov %eax,0x5b4(%esi) -0x0210e974 <do_sys_vm86+276>: testb $0x1,0x4c(%edi) -0x0210e978 <do_sys_vm86+280>: jne 0x210e990 <do_sys_vm86+304> -0x0210e97a <do_sys_vm86+282>: mov 0x4(%esi),%edx -0x0210e97d <do_sys_vm86+285>: xor %eax,%eax -0x0210e97f <do_sys_vm86+287>: mov %eax,%fs -0x0210e981 <do_sys_vm86+289>: mov %eax,%gs -0x0210e983 <do_sys_vm86+291>: mov %edi,%esp -0x0210e985 <do_sys_vm86+293>: mov %edx,%ebp -0x0210e987 <do_sys_vm86+295>: jmp 0xfffeb100 <resume_userspace> -0x0210e98c <do_sys_vm86+300>: pop %ebx -0x0210e98d <do_sys_vm86+301>: pop %esi -0x0210e98e <do_sys_vm86+302>: pop %edi -0x0210e98f <do_sys_vm86+303>: ret -0x0210e990 <do_sys_vm86+304>: push %esi -0x0210e991 <do_sys_vm86+305>: call 0x210e5b0 <mark_screen_rdonly> -0x0210e996 <do_sys_vm86+310>: pop %eax -0x0210e997 <do_sys_vm86+311>: jmp 0x210e97a <do_sys_vm86+282> -0x0210e999 <do_sys_vm86+313>: call 0x21222c0 <preempt_schedule> -0x0210e99e <do_sys_vm86+318>: jmp 0x210e96b <do_sys_vm86+267> -0x0210e9a0 <do_sys_vm86+320>: mov 0x24(%edx),%ax -0x0210e9a4 <do_sys_vm86+324>: mov %ax,0x10(%ecx) -0x0210e9a8 <do_sys_vm86+328>: mov $0x174,%ecx -0x0210e9ad <do_sys_vm86+333>: mov 0x24(%edx),%eax -0x0210e9b0 <do_sys_vm86+336>: xor %edx,%edx -0x0210e9b2 <do_sys_vm86+338>: wrmsr -0x0210e9b4 <do_sys_vm86+340>: jmp 0x210e95c <do_sys_vm86+252> -0x0210e9b6 <do_sys_vm86+342>: movl $0x0,0x5bc(%esi) -0x0210e9c0 <do_sys_vm86+352>: jmp 0x210e8d8 <do_sys_vm86+120> -0x0210e9c5 <do_sys_vm86+357>: cmp $0x4,%eax -0x0210e9c8 <do_sys_vm86+360>: jne 0x210e8ce <do_sys_vm86+110> -0x0210e9ce <do_sys_vm86+366>: movl $0x47000,0x5bc(%esi) -0x0210e9d8 <do_sys_vm86+376>: jmp 0x210e8d8 <do_sys_vm86+120> -0x0210e9dd <do_sys_vm86+381>: lea 0x0(%esi),%esi -0x0210e9e0 <do_sys_vm86+384>: movl $0x7000,0x5bc(%esi) -0x0210e9ea <do_sys_vm86+394>: jmp 0x210e8d8 <do_sys_vm86+120> +0x0210e969 <do_sys_vm86+265>: jne 0x210e9a9 <do_sys_vm86+329> +0x0210e96b <do_sys_vm86+267>: push $0x255f121 +0x0210e970 <do_sys_vm86+272>: call 0x21285a0 <printk> +0x0210e975 <do_sys_vm86+277>: mov 0x50(%edi),%eax +0x0210e978 <do_sys_vm86+280>: mov %eax,0x5b4(%esi) +0x0210e97e <do_sys_vm86+286>: pop %eax +0x0210e97f <do_sys_vm86+287>: testb $0x1,0x4c(%edi) +0x0210e983 <do_sys_vm86+291>: jne 0x210e9a0 <do_sys_vm86+320> +0x0210e985 <do_sys_vm86+293>: mov 0x4(%esi),%edx +0x0210e988 <do_sys_vm86+296>: xor %eax,%eax +0x0210e98a <do_sys_vm86+298>: mov %eax,%fs +0x0210e98c <do_sys_vm86+300>: mov %eax,%gs +0x0210e98e <do_sys_vm86+302>: mov %edi,%esp +0x0210e990 <do_sys_vm86+304>: mov %edx,%ebp +0x0210e992 <do_sys_vm86+306>: jmp 0xfffeb100 <resume_userspace> +0x0210e997 <do_sys_vm86+311>: pop %ebx +0x0210e998 <do_sys_vm86+312>: pop %esi +0x0210e999 <do_sys_vm86+313>: pop %edi +0x0210e99a <do_sys_vm86+314>: ret +0x0210e99b <do_sys_vm86+315>: nop +0x0210e99c <do_sys_vm86+316>: lea 0x0(%esi,1),%esi +0x0210e9a0 <do_sys_vm86+320>: push %esi +0x0210e9a1 <do_sys_vm86+321>: call 0x210e5b0 <mark_screen_rdonly> +0x0210e9a6 <do_sys_vm86+326>: pop %eax +0x0210e9a7 <do_sys_vm86+327>: jmp 0x210e985 <do_sys_vm86+293> +0x0210e9a9 <do_sys_vm86+329>: call 0x21222d0 <preempt_schedule> +0x0210e9ae <do_sys_vm86+334>: jmp 0x210e96b <do_sys_vm86+267> +0x0210e9b0 <do_sys_vm86+336>: mov 0x24(%edx),%ax +0x0210e9b4 <do_sys_vm86+340>: mov %ax,0x10(%ecx) +0x0210e9b8 <do_sys_vm86+344>: mov $0x174,%ecx +0x0210e9bd <do_sys_vm86+349>: mov 0x24(%edx),%eax +0x0210e9c0 <do_sys_vm86+352>: xor %edx,%edx +0x0210e9c2 <do_sys_vm86+354>: wrmsr +0x0210e9c4 <do_sys_vm86+356>: jmp 0x210e95c <do_sys_vm86+252> +0x0210e9c6 <do_sys_vm86+358>: movl $0x0,0x5bc(%esi) +0x0210e9d0 <do_sys_vm86+368>: jmp 0x210e8d8 <do_sys_vm86+120> +0x0210e9d5 <do_sys_vm86+373>: cmp $0x4,%eax +0x0210e9d8 <do_sys_vm86+376>: jne 0x210e8ce <do_sys_vm86+110> +0x0210e9de <do_sys_vm86+382>: movl $0x47000,0x5bc(%esi) +0x0210e9e8 <do_sys_vm86+392>: jmp 0x210e8d8 <do_sys_vm86+120> +0x0210e9ed <do_sys_vm86+397>: lea 0x0(%esi),%esi +0x0210e9f0 <do_sys_vm86+400>: movl $0x7000,0x5bc(%esi) +0x0210e9fa <do_sys_vm86+410>: jmp 0x210e8d8 <do_sys_vm86+120> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-17 23:14 ` Zwane Mwaikambo @ 2003-11-18 7:21 ` Zwane Mwaikambo 2003-11-18 15:47 ` Linus Torvalds 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-18 7:21 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Mon, 17 Nov 2003, Zwane Mwaikambo wrote: > A little bird told me to send diffs... But there is a lot of noise due to > offsets i'm afraid. Another note from our avian friends; i seem to have sent a slightly different dump from the patch, although they do both achieve the same effect. I shall append it for completeness. 0x0210e860 <do_sys_vm86+0>: push %edi 0x0210e861 <do_sys_vm86+1>: mov $0xffffe000,%eax 0x0210e866 <do_sys_vm86+6>: push %esi 0x0210e867 <do_sys_vm86+7>: and %esp,%eax 0x0210e869 <do_sys_vm86+9>: push %ebx 0x0210e86a <do_sys_vm86+10>: mov 0x10(%esp,1),%edi 0x0210e86e <do_sys_vm86+14>: mov 0x14(%esp,1),%esi 0x0210e872 <do_sys_vm86+18>: movl $0x0,0x1c(%edi) 0x0210e879 <do_sys_vm86+25>: movl $0x0,0x20(%edi) 0x0210e880 <do_sys_vm86+32>: mov (%eax),%edx 0x0210e882 <do_sys_vm86+34>: mov 0x30(%edi),%eax 0x0210e885 <do_sys_vm86+37>: mov %eax,0x5b8(%edx) 0x0210e88b <do_sys_vm86+43>: mov 0x30(%edi),%edx 0x0210e88e <do_sys_vm86+46>: mov 0xbc(%edi),%eax 0x0210e894 <do_sys_vm86+52>: and $0xdd5,%edx 0x0210e89a <do_sys_vm86+58>: mov %edx,0x30(%edi) 0x0210e89d <do_sys_vm86+61>: mov 0x30(%eax),%eax 0x0210e8a0 <do_sys_vm86+64>: and $0xfffff22a,%eax 0x0210e8a5 <do_sys_vm86+69>: or %eax,%edx 0x0210e8a7 <do_sys_vm86+71>: mov 0x54(%edi),%eax 0x0210e8aa <do_sys_vm86+74>: or $0x20000,%edx 0x0210e8b0 <do_sys_vm86+80>: cmp $0x3,%eax 0x0210e8b3 <do_sys_vm86+83>: mov %edx,0x30(%edi) 0x0210e8b6 <do_sys_vm86+86>: je 0x210e9f0 <do_sys_vm86+400> 0x0210e8bc <do_sys_vm86+92>: cmp $0x3,%eax 0x0210e8bf <do_sys_vm86+95>: ja 0x210e9d5 <do_sys_vm86+373> 0x0210e8c5 <do_sys_vm86+101>: cmp $0x2,%eax 0x0210e8c8 <do_sys_vm86+104>: je 0x210e9c6 <do_sys_vm86+358> 0x0210e8ce <do_sys_vm86+110>: movl $0x247000,0x5bc(%esi) 0x0210e8d8 <do_sys_vm86+120>: mov 0xbc(%edi),%eax 0x0210e8de <do_sys_vm86+126>: movl $0x0,0x18(%eax) 0x0210e8e5 <do_sys_vm86+133>: mov 0x360(%esi),%eax 0x0210e8eb <do_sys_vm86+139>: mov %eax,0x5c0(%esi) 0x0210e8f1 <do_sys_vm86+145>: movl %fs,0x5c4(%esi) 0x0210e8f7 <do_sys_vm86+151>: movl %gs,0x5c8(%esi) 0x0210e8fd <do_sys_vm86+157>: mov $0xffffe000,%ebx 0x0210e902 <do_sys_vm86+162>: and %esp,%ebx 0x0210e904 <do_sys_vm86+164>: mov 0x14(%ebx),%eax 0x0210e907 <do_sys_vm86+167>: inc %eax 0x0210e908 <do_sys_vm86+168>: mov %eax,0x14(%ebx) 0x0210e90b <do_sys_vm86+171>: mov 0x10(%ebx),%eax 0x0210e90e <do_sys_vm86+174>: mov 0x4(%esi),%edx 0x0210e911 <do_sys_vm86+177>: shl $0x9,%eax 0x0210e914 <do_sys_vm86+180>: lea 0x26ff000(%eax),%ecx 0x0210e91a <do_sys_vm86+186>: lea 0x4c(%edi),%eax 0x0210e91d <do_sys_vm86+189>: mov %eax,0x360(%esi) 0x0210e923 <do_sys_vm86+195>: sub 0x1c(%edx),%eax 0x0210e926 <do_sys_vm86+198>: add 0x20(%edx),%eax 0x0210e929 <do_sys_vm86+201>: mov %eax,0x4(%ecx) 0x0210e92c <do_sys_vm86+204>: mov 0x25fe52c,%eax 0x0210e931 <do_sys_vm86+209>: test $0x800,%eax 0x0210e936 <do_sys_vm86+214>: je 0x210e942 <do_sys_vm86+226> 0x0210e938 <do_sys_vm86+216>: movl $0x0,0x364(%esi) 0x0210e942 <do_sys_vm86+226>: lea 0x340(%esi),%edx 0x0210e948 <do_sys_vm86+232>: mov 0x20(%edx),%eax 0x0210e94b <do_sys_vm86+235>: mov %eax,0x4(%ecx) 0x0210e94e <do_sys_vm86+238>: mov 0x10(%ecx),%ax 0x0210e952 <do_sys_vm86+242>: and $0xffff,%eax 0x0210e957 <do_sys_vm86+247>: cmp 0x24(%edx),%eax 0x0210e95a <do_sys_vm86+250>: jne 0x210e9b0 <do_sys_vm86+336> 0x0210e95c <do_sys_vm86+252>: mov 0x14(%ebx),%eax 0x0210e95f <do_sys_vm86+255>: dec %eax 0x0210e960 <do_sys_vm86+256>: mov %eax,0x14(%ebx) 0x0210e963 <do_sys_vm86+259>: mov 0x8(%ebx),%eax 0x0210e966 <do_sys_vm86+262>: and $0x8,%eax 0x0210e969 <do_sys_vm86+265>: jne 0x210e9a9 <do_sys_vm86+329> 0x0210e96b <do_sys_vm86+267>: mov 0x50(%edi),%eax 0x0210e96e <do_sys_vm86+270>: mov %eax,0x5b4(%esi) 0x0210e974 <do_sys_vm86+276>: testb $0x1,0x4c(%edi) 0x0210e978 <do_sys_vm86+280>: jne 0x210e9a0 <do_sys_vm86+320> 0x0210e97a <do_sys_vm86+282>: push $0x255f121 0x0210e97f <do_sys_vm86+287>: call 0x21285a0 <printk> 0x0210e984 <do_sys_vm86+292>: mov 0x4(%esi),%edx 0x0210e987 <do_sys_vm86+295>: xor %eax,%eax 0x0210e989 <do_sys_vm86+297>: mov %eax,%fs 0x0210e98b <do_sys_vm86+299>: mov %eax,%gs 0x0210e98d <do_sys_vm86+301>: mov %edi,%esp 0x0210e98f <do_sys_vm86+303>: mov %edx,%ebp 0x0210e991 <do_sys_vm86+305>: jmp 0xfffeb100 <resume_userspace> 0x0210e996 <do_sys_vm86+310>: pop %esi 0x0210e997 <do_sys_vm86+311>: pop %ebx 0x0210e998 <do_sys_vm86+312>: pop %esi 0x0210e999 <do_sys_vm86+313>: pop %edi 0x0210e99a <do_sys_vm86+314>: ret 0x0210e99b <do_sys_vm86+315>: nop 0x0210e99c <do_sys_vm86+316>: lea 0x0(%esi,1),%esi 0x0210e9a0 <do_sys_vm86+320>: push %esi 0x0210e9a1 <do_sys_vm86+321>: call 0x210e5b0 <mark_screen_rdonly> 0x0210e9a6 <do_sys_vm86+326>: pop %eax 0x0210e9a7 <do_sys_vm86+327>: jmp 0x210e97a <do_sys_vm86+282> 0x0210e9a9 <do_sys_vm86+329>: call 0x21222d0 <preempt_schedule> 0x0210e9ae <do_sys_vm86+334>: jmp 0x210e96b <do_sys_vm86+267> 0x0210e9b0 <do_sys_vm86+336>: mov 0x24(%edx),%ax 0x0210e9b4 <do_sys_vm86+340>: mov %ax,0x10(%ecx) 0x0210e9b8 <do_sys_vm86+344>: mov $0x174,%ecx 0x0210e9bd <do_sys_vm86+349>: mov 0x24(%edx),%eax 0x0210e9c0 <do_sys_vm86+352>: xor %edx,%edx 0x0210e9c2 <do_sys_vm86+354>: wrmsr 0x0210e9c4 <do_sys_vm86+356>: jmp 0x210e95c <do_sys_vm86+252> 0x0210e9c6 <do_sys_vm86+358>: movl $0x0,0x5bc(%esi) 0x0210e9d0 <do_sys_vm86+368>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9d5 <do_sys_vm86+373>: cmp $0x4,%eax 0x0210e9d8 <do_sys_vm86+376>: jne 0x210e8ce <do_sys_vm86+110> 0x0210e9de <do_sys_vm86+382>: movl $0x47000,0x5bc(%esi) 0x0210e9e8 <do_sys_vm86+392>: jmp 0x210e8d8 <do_sys_vm86+120> 0x0210e9ed <do_sys_vm86+397>: lea 0x0(%esi),%esi 0x0210e9f0 <do_sys_vm86+400>: movl $0x7000,0x5bc(%esi) 0x0210e9fa <do_sys_vm86+410>: jmp 0x210e8d8 <do_sys_vm86+120> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 7:21 ` Zwane Mwaikambo @ 2003-11-18 15:47 ` Linus Torvalds 2003-11-18 16:16 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Linus Torvalds @ 2003-11-18 15:47 UTC (permalink / raw) To: Zwane Mwaikambo Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, 18 Nov 2003, Zwane Mwaikambo wrote: > > Another note from our avian friends; i seem to have sent a slightly > different dump from the patch, although they do both achieve the same > effect. I shall append it for completeness. Hmm. I don't see anything. However, it's a lot easier to read the gcc-generated assembly ("make arch/i386/kernel/vm86.s") than it is to read the objdump disassembly. It's also a lot easier to see what the assembly language is when giving the -fno-reorder-blocks switch to gcc. Without it, modern gcc's tend to have _way_ too many jumps around. But maybe that actually changes the behaviour too. Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 15:47 ` Linus Torvalds @ 2003-11-18 16:16 ` Zwane Mwaikambo 2003-11-18 16:37 ` Linus Torvalds 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-18 16:16 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, 18 Nov 2003, Linus Torvalds wrote: > Hmm. I don't see anything. However, it's a lot easier to read the > gcc-generated assembly ("make arch/i386/kernel/vm86.s") than it is to read > the objdump disassembly. > > > It's also a lot easier to see what the assembly language is when giving > the > > -fno-reorder-blocks I'll recompile and verify that the bug can be reproduced and worked around with that flag. > switch to gcc. Without it, modern gcc's tend to have _way_ too many jumps > around. But maybe that actually changes the behaviour too. Here are diffs from the do_sys_vm86 only. --- asm-before 2003-11-18 10:56:02.967643808 -0500 +++ asm-after 2003-11-18 10:55:37.880457640 -0500 @@ -897,6 +897,10 @@ .LFE473: .Lfe4: .size sys_vm86,.Lfe4-sys_vm86 + .section .rodata.str1.1 +.LC6: + .string "ooh la la\n" + .text .p2align 4,,15 .type do_sys_vm86,@function do_sys_vm86: @@ -1053,29 +1057,37 @@ jne .L213 .L210: .loc 1 315 0 + pushl $.LC6 +.LCFI98: + call printk + .loc 1 316 0 movl 4(%esi), %edx #APP xorl %eax,%eax; movl %eax,%fs; movl %eax,%gs movl %edi,%esp movl %edx,%ebp jmp resume_userspace - .loc 1 323 0 #NO_APP - popl %ebx -.LCFI98: +.LBE53: popl %esi .LCFI99: - popl %edi + .loc 1 324 0 + popl %ebx .LCFI100: + popl %esi +.LCFI101: + popl %edi +.LCFI102: ret .loc 1 313 0 .p2align 4,,7 .L213: +.LBB65: pushl %esi -.LCFI101: +.LCFI103: call mark_screen_rdonly popl %eax -.LCFI102: +.LCFI104: jmp .L210 .loc 1 310 0 .L212: @@ -1083,7 +1095,7 @@ jmp .L197 .loc 14 454 0 .L211: -.LBB65: +.LBB66: movw 36(%edx), %ax movw %ax, 16(%ecx) .loc 14 455 0 @@ -1097,7 +1109,7 @@ .p2align 4,,7 .L183: .loc 1 283 0 -.LBE65: +.LBE66: movl $0, 1468(%esi) .loc 1 284 0 jmp .L182 @@ -1115,7 +1127,7 @@ movl $28672, 1468(%esi) .loc 1 287 0 jmp .L182 -.LBE53: +.LBE65: .LFE475: .Lfe5: .size do_sys_vm86,.Lfe5-do_sys_vm86 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 16:16 ` Zwane Mwaikambo @ 2003-11-18 16:37 ` Linus Torvalds 2003-11-18 17:08 ` Zwane Mwaikambo 2003-11-19 20:32 ` Matt Mackall 0 siblings, 2 replies; 52+ messages in thread From: Linus Torvalds @ 2003-11-18 16:37 UTC (permalink / raw) To: Zwane Mwaikambo Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, 18 Nov 2003, Zwane Mwaikambo wrote: > > Here are diffs from the do_sys_vm86 only. Ok. Much more readable. And there is something very suspicious there. The code with and without the printk() looks _identical_ apart from some trivial label renumbering, and the added pushl $.LC6 call printk .. asm .. popl %esi which all looks fine (esi is dead at that point, so the compiler is just using a "popl" as a shorter form of "addl $4,%esp"). Btw, you seem to compile with debugging, which makes the assembly language pretty much unreadable and accounts for most of the differences: the line numbers change. If you compile a kernel where the line numbers don't change (by commenting _out_ the printk rather than removing the whole line), your diff would be more readable. Anyway, there are _zero_ differences. Just for fun, try this: move the "printk()" to _below_ the "asm" statement. It will never actually get executed, but if it's an issue of some subtle code or data placement things (cache lines etc), maybe that also hides the oops, since all the same code and data will be generated, just not run... Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 16:37 ` Linus Torvalds @ 2003-11-18 17:08 ` Zwane Mwaikambo 2003-11-18 17:38 ` Martin J. Bligh 2003-11-19 20:32 ` Matt Mackall 1 sibling, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-18 17:08 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, 18 Nov 2003, Linus Torvalds wrote: > Ok. Much more readable. > > And there is something very suspicious there. > > The code with and without the printk() looks _identical_ apart from some > trivial label renumbering, and the added > > pushl $.LC6 > call printk > .. asm .. > popl %esi > > which all looks fine (esi is dead at that point, so the compiler is just > using a "popl" as a shorter form of "addl $4,%esp"). > > Btw, you seem to compile with debugging, which makes the assembly > language pretty much unreadable and accounts for most of the > differences: the line numbers change. If you compile a kernel where the > line numbers don't change (by commenting _out_ the printk rather than > removing the whole line), your diff would be more readable. Aha! Thanks for mentioning that, noted. > Anyway, there are _zero_ differences. > > Just for fun, try this: move the "printk()" to _below_ the "asm" > statement. It will never actually get executed, but if it's an issue of > some subtle code or data placement things (cache lines etc), maybe that > also hides the oops, since all the same code and data will be generated, > just not run... Ok i just tried that and it still fails. Matt Mackall suggested i also try writing a minimal printk which has the same effect. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 17:08 ` Zwane Mwaikambo @ 2003-11-18 17:38 ` Martin J. Bligh 2003-11-18 17:22 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Martin J. Bligh @ 2003-11-18 17:38 UTC (permalink / raw) To: Zwane Mwaikambo, Linus Torvalds Cc: Ingo Molnar, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins >> Btw, you seem to compile with debugging, which makes the assembly >> language pretty much unreadable and accounts for most of the >> differences: the line numbers change. If you compile a kernel where the >> line numbers don't change (by commenting _out_ the printk rather than >> removing the whole line), your diff would be more readable. > > Aha! Thanks for mentioning that, noted. > >> Anyway, there are _zero_ differences. >> >> Just for fun, try this: move the "printk()" to _below_ the "asm" >> statement. It will never actually get executed, but if it's an issue of >> some subtle code or data placement things (cache lines etc), maybe that >> also hides the oops, since all the same code and data will be generated, >> just not run... > > Ok i just tried that and it still fails. Matt Mackall suggested i also try > writing a minimal printk which has the same effect. The other thing I've found printks to hide before is timing bugs / races. Unfortunately I can't see one here, but maybe someone else can ;-) Maybe inserting a 1ms delay or something in place of the printk would have the same effect? M. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 17:38 ` Martin J. Bligh @ 2003-11-18 17:22 ` Zwane Mwaikambo 0 siblings, 0 replies; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-18 17:22 UTC (permalink / raw) To: Martin J. Bligh Cc: Linus Torvalds, Ingo Molnar, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, 18 Nov 2003, Martin J. Bligh wrote: > The other thing I've found printks to hide before is timing bugs / races. > Unfortunately I can't see one here, but maybe someone else can ;-) > Maybe inserting a 1ms delay or something in place of the printk would > have the same effect? I've tried a number of timing related workarounds, namely; schedule_timeout(2*HZ) and some long spinning loops. I've also thrown a schedule() in there at some point. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 16:37 ` Linus Torvalds 2003-11-18 17:08 ` Zwane Mwaikambo @ 2003-11-19 20:32 ` Matt Mackall 2003-11-19 23:09 ` Matt Mackall 1 sibling, 1 reply; 52+ messages in thread From: Matt Mackall @ 2003-11-19 20:32 UTC (permalink / raw) To: Linus Torvalds Cc: Zwane Mwaikambo, Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Tue, Nov 18, 2003 at 08:37:25AM -0800, Linus Torvalds wrote: > > On Tue, 18 Nov 2003, Zwane Mwaikambo wrote: > > > > Here are diffs from the do_sys_vm86 only. > > Ok. Much more readable. > > And there is something very suspicious there. > > The code with and without the printk() looks _identical_ apart from some > trivial label renumbering, and the added > > pushl $.LC6 > call printk > .. asm .. > popl %esi > > which all looks fine (esi is dead at that point, so the compiler is just > using a "popl" as a shorter form of "addl $4,%esp"). > > Btw, you seem to compile with debugging, which makes the assembly > language pretty much unreadable and accounts for most of the > differences: the line numbers change. If you compile a kernel where the > line numbers don't change (by commenting _out_ the printk rather than > removing the whole line), your diff would be more readable. > > Anyway, there are _zero_ differences. > > Just for fun, try this: move the "printk()" to _below_ the "asm" > statement. It will never actually get executed, but if it's an issue of > some subtle code or data placement things (cache lines etc), maybe that > also hides the oops, since all the same code and data will be generated, > just not run... Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit doesn't help. So my suspicion is that the printk is changing the timing just enough on Zwane's box that he's getting a timer interrupt knocking him out of vm86 mode before he hits a fatal bit in the fault handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault, do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so there's probably something amiss in the trampoline code. -- Matt Mackall : http://www.selenic.com : Linux development and consulting ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 20:32 ` Matt Mackall @ 2003-11-19 23:09 ` Matt Mackall 2003-11-20 7:14 ` Zwane Mwaikambo 2003-11-20 7:44 ` Matt Mackall 0 siblings, 2 replies; 52+ messages in thread From: Matt Mackall @ 2003-11-19 23:09 UTC (permalink / raw) To: Linus Torvalds Cc: Zwane Mwaikambo, Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote: > > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit > doesn't help. So my suspicion is that the printk is changing the > timing just enough on Zwane's box that he's getting a timer interrupt > knocking him out of vm86 mode before he hits a fatal bit in the fault > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault, > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so > there's probably something amiss in the trampoline code. Some more datapoints: CPU distro compiler video X result K6-2/500 connectiva 9 2.96 trident 4.3 reboot (zwane) K6-2/500 connectiva 9 3.2.2 trident 4.3 reboot (zwane) Opteron 240 debian unstable 3.2 S3 4.2.1 reboot Athlon 2100 debian unstable 3.2 radeon 7500 4.2.1 works P4M 1800 debian unstable 3.2 radeon m7 4.2.1 reboot -- Matt Mackall : http://www.selenic.com : Linux development and consulting ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 23:09 ` Matt Mackall @ 2003-11-20 7:14 ` Zwane Mwaikambo 2003-11-20 7:44 ` Matt Mackall 1 sibling, 0 replies; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-20 7:14 UTC (permalink / raw) To: Matt Mackall Cc: Linus Torvalds, Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Wed, 19 Nov 2003, Matt Mackall wrote: > On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote: > > > > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my > > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit > > doesn't help. So my suspicion is that the printk is changing the > > timing just enough on Zwane's box that he's getting a timer interrupt > > knocking him out of vm86 mode before he hits a fatal bit in the fault > > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault, > > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so > > there's probably something amiss in the trampoline code. > > Some more datapoints: Thanks for trying those out, i got another one to add. > CPU distro compiler video X result > K6-2/500 connectiva 9 2.96 trident 4.3 reboot (zwane) > K6-2/500 connectiva 9 3.2.2 trident 4.3 reboot (zwane) > Opteron 240 debian unstable 3.2 S3 4.2.1 reboot > Athlon 2100 debian unstable 3.2 radeon 7500 4.2.1 works > P4M 1800 debian unstable 3.2 radeon m7 4.2.1 reboot P4/Xeon 2000 Fedora Core 1 3.3.2 ATI Rage XL 4.3.0 reboot ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 23:09 ` Matt Mackall 2003-11-20 7:14 ` Zwane Mwaikambo @ 2003-11-20 7:44 ` Matt Mackall 2003-11-20 7:53 ` Andrew Morton 2003-11-20 8:13 ` Matt Mackall 1 sibling, 2 replies; 52+ messages in thread From: Matt Mackall @ 2003-11-20 7:44 UTC (permalink / raw) To: Linus Torvalds Cc: Zwane Mwaikambo, Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Wed, Nov 19, 2003 at 05:09:28PM -0600, Matt Mackall wrote: > On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote: > > > > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my > > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit > > doesn't help. So my suspicion is that the printk is changing the > > timing just enough on Zwane's box that he's getting a timer interrupt > > knocking him out of vm86 mode before he hits a fatal bit in the fault > > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault, > > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so > > there's probably something amiss in the trampoline code. > > Some more datapoints: > > CPU distro compiler video X result > K6-2/500 connectiva 9 2.96 trident 4.3 reboot (zwane) > K6-2/500 connectiva 9 3.2.2 trident 4.3 reboot (zwane) > Opteron 240 debian unstable 3.2 S3 4.2.1 reboot > Athlon 2100 debian unstable 3.2 radeon 7500 4.2.1 works > P4M 1800 debian unstable 3.2 radeon m7 4.2.1 reboot And indeed it does turn out to be a problem with the trampoline mechanics. The fix for -mm4: Fix triple faulting on some boxes with 4G/4G mm-mpm/arch/i386/kernel/vm86.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN arch/i386/kernel/vm86.c~virtual-esp arch/i386/kernel/vm86.c --- mm/arch/i386/kernel/vm86.c~virtual-esp 2003-11-20 01:36:32.000000000 -0600 +++ mm-mpm/arch/i386/kernel/vm86.c 2003-11-20 01:36:32.000000000 -0600 @@ -306,7 +306,7 @@ static void do_sys_vm86(struct kernel_vm tss->esp0 = virtual_esp0(tsk); if (cpu_has_sep) tsk->thread.sysenter_cs = 0; - load_esp0(tss, &tsk->thread); + load_virtual_esp0(tss, tsk); put_cpu(); tsk->thread.screen_bitmap = info->screen_bitmap; _ -- Matt Mackall : http://www.selenic.com : Linux development and consulting ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-20 7:44 ` Matt Mackall @ 2003-11-20 7:53 ` Andrew Morton 2003-11-20 8:13 ` Matt Mackall 1 sibling, 0 replies; 52+ messages in thread From: Andrew Morton @ 2003-11-20 7:53 UTC (permalink / raw) To: Matt Mackall; +Cc: torvalds, zwane, mingo, mbligh, linux-kernel, linux-mm, hugh Matt Mackall <mpm@selenic.com> wrote: > > - load_esp0(tss, &tsk->thread); > + load_virtual_esp0(tss, tsk); Thanks guys. Now I'll have to put something else in there to keep you amused ;) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-20 7:44 ` Matt Mackall 2003-11-20 7:53 ` Andrew Morton @ 2003-11-20 8:13 ` Matt Mackall 1 sibling, 0 replies; 52+ messages in thread From: Matt Mackall @ 2003-11-20 8:13 UTC (permalink / raw) To: Linus Torvalds Cc: Zwane Mwaikambo, Ingo Molnar, Martin J. Bligh, Andrew Morton, Linux Kernel, linux-mm, Hugh Dickins On Thu, Nov 20, 2003 at 01:44:05AM -0600, Matt Mackall wrote: > On Wed, Nov 19, 2003 at 05:09:28PM -0600, Matt Mackall wrote: > > On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote: > > > > > > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my > > > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit > > > doesn't help. So my suspicion is that the printk is changing the > > > timing just enough on Zwane's box that he's getting a timer interrupt > > > knocking him out of vm86 mode before he hits a fatal bit in the fault > > > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault, > > > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so > > > there's probably something amiss in the trampoline code. > > > > Some more datapoints: > > > > CPU distro compiler video X result > > K6-2/500 connectiva 9 2.96 trident 4.3 reboot (zwane) > > K6-2/500 connectiva 9 3.2.2 trident 4.3 reboot (zwane) > > Opteron 240 debian unstable 3.2 S3 4.2.1 reboot > > Athlon 2100 debian unstable 3.2 radeon 7500 4.2.1 works > > P4M 1800 debian unstable 3.2 radeon m7 4.2.1 reboot > > And indeed it does turn out to be a problem with the trampoline > mechanics. The fix for -mm4: Cleanup, as pointed out by Zwane: Fix triple faulting on some boxes with 4G/4G mm-mpm/arch/i386/kernel/vm86.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN arch/i386/kernel/vm86.c~virtual-esp arch/i386/kernel/vm86.c --- mm/arch/i386/kernel/vm86.c~virtual-esp 2003-11-20 01:36:32.000000000 -0600 +++ mm-mpm/arch/i386/kernel/vm86.c 2003-11-20 02:08:38.000000000 -0600 @@ -303,10 +303,9 @@ static void do_sys_vm86(struct kernel_vm tss = init_tss + get_cpu(); tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0; - tss->esp0 = virtual_esp0(tsk); if (cpu_has_sep) tsk->thread.sysenter_cs = 0; - load_esp0(tss, &tsk->thread); + load_virtual_esp0(tss, tsk); put_cpu(); tsk->thread.screen_bitmap = info->screen_bitmap; _ -- Matt Mackall : http://www.selenic.com : Linux development and consulting ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton ` (3 preceding siblings ...) 2003-11-14 5:07 ` 2.6.0-test9-mm3 Martin J. Bligh @ 2003-11-14 19:08 ` Martin J. Bligh 2003-11-14 18:59 ` 2.6.0-test9-mm3 Andrew Morton 2003-11-14 19:10 ` 2.6.0-test9-mm3 Badari Pulavarty 4 siblings, 2 replies; 52+ messages in thread From: Martin J. Bligh @ 2003-11-14 19:08 UTC (permalink / raw) To: Andrew Morton, linux-kernel, linux-mm > - Several ext2 and ext3 allocator fixes. These need serious testing on big > SMP. OK, ext3 survived a swatting on the 16-way as well. It's still slow as snot, but it does work ;-) No changes from before, methinks. Diffprofile for kernbench (-j) from ext2 to ext3 on mm3 27022 16.3% total 24069 53.3% default_idle 583 2.4% page_remove_rmap 539 248.4% fd_install 478 388.6% __blk_queue_bounce 319 4.0% __d_lookup 220 122.9% may_open 204 68.2% filemap_nopage 124 0.0% journal_add_journal_head 122 321.1% __find_get_block_slow 122 0.0% do_get_write_access 101 57.1% generic_fillattr ... -52 -73.2% .text.lock.highmem -52 -94.5% generic_file_read -53 -18.7% do_generic_mapping_read -58 -3.3% do_no_page -65 -13.0% page_address -65 -60.2% kmap_high -74 -100.0% grab_block -75 -3.3% do_page_fault -85 -1.9% __copy_from_user_ll -273 -19.5% link_path_walk -299 -6.5% find_get_page -758 -100.0% generic_file_open SDET: 1726439 214.7% total 1383611 345.4% default_idle 115417 0.0% .text.lock.transaction 79362 0.0% find_next_usable_block 38003 0.0% do_get_write_access 32429 2316.4% __down 31231 0.0% journal_dirty_metadata 15114 553.8% schedule 14350 1253.3% __wake_up 13459 0.0% start_this_handle 13100 0.0% journal_stop ... -1105 -25.1% copy_mm -1144 -100.0% generic_file_open -1205 -45.0% .text.lock.dec_and_lock -1342 -100.0% ext2_new_inode -1365 -50.5% follow_mount -1453 -100.0% grab_block -1580 -30.5% remove_shared_vm_struct -1759 -11.0% copy_page_range -2145 -18.4% __d_lookup -2157 -35.6% path_lookup -2222 -33.7% atomic_dec_and_lock -2813 -25.0% release_pages -3764 -19.1% zap_pte_range -8954 -21.2% page_add_rmap -22707 -25.0% page_remove_rmap ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 19:08 ` 2.6.0-test9-mm3 Martin J. Bligh @ 2003-11-14 18:59 ` Andrew Morton 2003-11-14 19:32 ` 2.6.0-test9-mm3 Mike Fedyk 2003-11-14 19:10 ` 2.6.0-test9-mm3 Badari Pulavarty 1 sibling, 1 reply; 52+ messages in thread From: Andrew Morton @ 2003-11-14 18:59 UTC (permalink / raw) To: Martin J. Bligh; +Cc: linux-kernel, linux-mm "Martin J. Bligh" <mbligh@aracnet.com> wrote: > > > > > - Several ext2 and ext3 allocator fixes. These need serious testing on big > > SMP. > > OK, ext3 survived a swatting on the 16-way as well> Great, thanks. > It's still slow as snot, but it does work ;-) I think SDET generates storms of metadata updates. Making the journal larger may help get that idle time down. Probably the default journal size is too small nowadays. Most tests seem to run faster when it is enlarged. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 18:59 ` 2.6.0-test9-mm3 Andrew Morton @ 2003-11-14 19:32 ` Mike Fedyk 2003-11-14 20:27 ` 2.6.0-test9-mm3 John Stoffel 0 siblings, 1 reply; 52+ messages in thread From: Mike Fedyk @ 2003-11-14 19:32 UTC (permalink / raw) To: Andrew Morton; +Cc: Martin J. Bligh, linux-kernel, linux-mm On Fri, Nov 14, 2003 at 10:59:47AM -0800, Andrew Morton wrote: > "Martin J. Bligh" <mbligh@aracnet.com> wrote: > > > > > > > > > - Several ext2 and ext3 allocator fixes. These need serious testing on big > > > SMP. > > > > OK, ext3 survived a swatting on the 16-way as well> > > Great, thanks. > > > It's still slow as snot, but it does work ;-) > > I think SDET generates storms of metadata updates. Making the journal > larger may help get that idle time down. > > Probably the default journal size is too small nowadays. Most tests seem > to run faster when it is enlarged. Or maybe if it didn't start sync committing from the journal once it hits 50%. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 19:32 ` 2.6.0-test9-mm3 Mike Fedyk @ 2003-11-14 20:27 ` John Stoffel 2003-11-15 1:01 ` 2.6.0-test9-mm3 Mike Fedyk 0 siblings, 1 reply; 52+ messages in thread From: John Stoffel @ 2003-11-14 20:27 UTC (permalink / raw) To: Mike Fedyk; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm Mike> Or maybe if it didn't start sync committing from the journal Mike> once it hits 50%. Instead of using a percentage like this, would it make sense to flush the journal when there are only N number of free journal slots/entries left? Now the question is how to compute N in a sane way that works for small (memory) systems, as well as for larger systems. You don't want to grow N too aggresively, or base it on the memory of the system, do you? When you have a 20mb journal, maybe starting writeout after 10mb is used makes sense, because you've only got 10 transaction slots open. But when you have a 200mb journal, does it make sense to start writeout when you only have 100 transaction slots left? Since I don't know the internals of Ext3 at all, I'm probably completely missing the idea here, but my gut feeling is that the scaling we use in these cases shouldn't be linear at all, but more likely inverse logyrythmic instead. Basically, the larger we get with a resource, the slower we grow our useage, or the smaller we grow the absolute size of the writeout buffer(s). Hmmm... this doesn't sound clear even to me. But the idea I think I'm trying to get at is that if we have X size of a journal, we want to start writeout when we have X/2 available. But when we have Y size of a journal, where Y is X*10 (or larger), we don't want Y/2 as the cutover point, we want something like Y/10. The idea is that we grow the denominator here at a slow rate, since it will shrink the free buffer percentage nicely, yet not let us get too close to a truly zero sized buffer. X X/N ----- -------- 10 5 100 10 1000 25 10000 125 Does this make any sense to anyone? John ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 20:27 ` 2.6.0-test9-mm3 John Stoffel @ 2003-11-15 1:01 ` Mike Fedyk 0 siblings, 0 replies; 52+ messages in thread From: Mike Fedyk @ 2003-11-15 1:01 UTC (permalink / raw) To: John Stoffel; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm On Fri, Nov 14, 2003 at 03:27:01PM -0500, John Stoffel wrote: > You don't want to grow N too aggresively, or base it on the memory of > the system, do you? When you have a 20mb journal, maybe starting > writeout after 10mb is used makes sense, because you've only got 10 > transaction slots open. But when you have a 200mb journal, does it > make sense to start writeout when you only have 100 transaction slots > left? The minimum transaction size is one block (since ext3 is the only journaling FS to log entire blocks, instead of the specific logical changes made during the transaction), and your blocks are 1k, 2k, or 4k. Though many times you'll have several blocks per transaction since each transaction can change bitmaps, directory blocks, and etc. > Since I don't know the internals of Ext3 at all, I'm probably > completely missing the idea here, but my gut feeling is that the > scaling we use in these cases shouldn't be linear at all, but more > likely inverse logyrythmic instead. Basically, the larger we get with > a resource, the slower we grow our useage, or the smaller we grow the > absolute size of the writeout buffer(s). > > Hmmm... this doesn't sound clear even to me. But the idea I think I'm > trying to get at is that if we have X size of a journal, we want to > start writeout when we have X/2 available. But when we have Y size of > a journal, where Y is X*10 (or larger), we don't want Y/2 as the > cutover point, we want something like Y/10. The idea is that we grow > the denominator here at a slow rate, since it will shrink the free > buffer percentage nicely, yet not let us get too close to a truly zero > sized buffer. Last I heard, ext3 will try to flush the journal with an async process and if that isn't able to keep up, once the journal hits 50% full, the system will write syncronously until the journal is empty (or was that until it was 25% full or less, I forget...). AFAIK everyone agrees that this is not optimal, but nobody's taken the time to fix it yet either. Mike ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 19:08 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 18:59 ` 2.6.0-test9-mm3 Andrew Morton @ 2003-11-14 19:10 ` Badari Pulavarty 2003-11-14 20:29 ` 2.6.0-test9-mm3 Martin J. Bligh 1 sibling, 1 reply; 52+ messages in thread From: Badari Pulavarty @ 2003-11-14 19:10 UTC (permalink / raw) To: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm On Friday 14 November 2003 11:08 am, Martin J. Bligh wrote: > > - Several ext2 and ext3 allocator fixes. These need serious testing on > > big SMP. > > OK, ext3 survived a swatting on the 16-way as well. It's still slow as > snot, but it does work ;-) No changes from before, methinks. > > Diffprofile for kernbench (-j) from ext2 to ext3 on mm3 > > 27022 16.3% total > 24069 53.3% default_idle > 583 2.4% page_remove_rmap > 539 248.4% fd_install > 478 388.6% __blk_queue_bounce What driver are you using ? Why are you bouncing ? Thanks, Badari ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 19:10 ` 2.6.0-test9-mm3 Badari Pulavarty @ 2003-11-14 20:29 ` Martin J. Bligh 2003-11-17 20:58 ` 2.6.0-test9-mm3 bill davidsen 0 siblings, 1 reply; 52+ messages in thread From: Martin J. Bligh @ 2003-11-14 20:29 UTC (permalink / raw) To: Badari Pulavarty, Andrew Morton, linux-kernel, linux-mm >> > - Several ext2 and ext3 allocator fixes. These need serious testing on >> > big SMP. >> >> OK, ext3 survived a swatting on the 16-way as well. It's still slow as >> snot, but it does work ;-) No changes from before, methinks. >> >> Diffprofile for kernbench (-j) from ext2 to ext3 on mm3 >> >> 27022 16.3% total >> 24069 53.3% default_idle >> 583 2.4% page_remove_rmap >> 539 248.4% fd_install >> 478 388.6% __blk_queue_bounce > > What driver are you using ? Why are you bouncing ? qlogicisp. Because the driver is crap? ;-) M. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: 2.6.0-test9-mm3 2003-11-14 20:29 ` 2.6.0-test9-mm3 Martin J. Bligh @ 2003-11-17 20:58 ` bill davidsen 0 siblings, 0 replies; 52+ messages in thread From: bill davidsen @ 2003-11-17 20:58 UTC (permalink / raw) To: linux-kernel In article <100480000.1068841761@flay>, Martin J. Bligh <mbligh@aracnet.com> wrote: | >> > - Several ext2 and ext3 allocator fixes. These need serious testing on | >> > big SMP. | >> | >> OK, ext3 survived a swatting on the 16-way as well. It's still slow as | >> snot, but it does work ;-) No changes from before, methinks. | >> | >> Diffprofile for kernbench (-j) from ext2 to ext3 on mm3 | >> | >> 27022 16.3% total | >> 24069 53.3% default_idle | >> 583 2.4% page_remove_rmap | >> 539 248.4% fd_install | >> 478 388.6% __blk_queue_bounce | > | > What driver are you using ? Why are you bouncing ? | | qlogicisp. Because the driver is crap? ;-) The question is, does that make your testing better or worse in terms of checking the new code? Clearly you have done a good job of checking the "disk can't keep up" case, is there a need to test further with a much higher transaction rate? I would assume that if there were lock issues they would have shown up, which is probably all that's needed. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
@ 2003-11-18 23:48 Jon Foster
2003-11-19 3:24 ` Zwane Mwaikambo
0 siblings, 1 reply; 52+ messages in thread
From: Jon Foster @ 2003-11-18 23:48 UTC (permalink / raw)
To: linux-kernel; +Cc: zwane
Hi,
> The other thing I've found printks to hide before is timing bugs / races.
> Unfortunately I can't see one here, but maybe someone else can ;-)
> Maybe inserting a 1ms delay or something in place of the printk would
> have the same effect?
One of my colleagues had an interesting bug caused by an
uninitialized variable - a printk() in the right place happened
to set the variable (which gcc had put in a register) to the
correct value for his code to work.
I've tried looking for uses of uninitialized registers in entry.S,
but the assembly there isn't easy to follow.
What happens if you replace the printk with assembly code
that clobbers eax, ecx, edx and (most of) eflags? (Assuming
I've remembered the calling convention correctly, those are
the registers that printk will be overwriting).
Kind regards,
Jon
^ permalink raw reply [flat|nested] 52+ messages in thread* Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-18 23:48 Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Jon Foster @ 2003-11-19 3:24 ` Zwane Mwaikambo 2003-11-19 5:45 ` Andrew Morton 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-19 3:24 UTC (permalink / raw) To: Jon Foster; +Cc: linux-kernel On Tue, 18 Nov 2003, Jon Foster wrote: > > The other thing I've found printks to hide before is timing bugs / races. > > Unfortunately I can't see one here, but maybe someone else can ;-) > > Maybe inserting a 1ms delay or something in place of the printk would > > have the same effect? > > One of my colleagues had an interesting bug caused by an > uninitialized variable - a printk() in the right place happened > to set the variable (which gcc had put in a register) to the > correct value for his code to work. Very nice =) > I've tried looking for uses of uninitialized registers in entry.S, > but the assembly there isn't easy to follow. I've walked that code and can't see anything wrong anywhere. > What happens if you replace the printk with assembly code > that clobbers eax, ecx, edx and (most of) eflags? (Assuming > I've remembered the calling convention correctly, those are > the registers that printk will be overwriting). Well i have tried a number of heavyweight functions, so far none of them have had the effect that a printk has had. It's also worth noting that a printk lookalike function such as the following, does not fix things either. asmlinkage int kooh_la_la(const char *fmt, ...) { return strlen(fmt); } ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 3:24 ` Zwane Mwaikambo @ 2003-11-19 5:45 ` Andrew Morton 2003-11-19 6:50 ` Zwane Mwaikambo 0 siblings, 1 reply; 52+ messages in thread From: Andrew Morton @ 2003-11-19 5:45 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: jon, linux-kernel Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote: > > I've walked that code and can't see anything wrong anywhere. fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split enabled. Have you tried a different compiler? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 5:45 ` Andrew Morton @ 2003-11-19 6:50 ` Zwane Mwaikambo 2003-11-19 7:24 ` Linus Torvalds 0 siblings, 1 reply; 52+ messages in thread From: Zwane Mwaikambo @ 2003-11-19 6:50 UTC (permalink / raw) To: Andrew Morton; +Cc: jon, linux-kernel On Tue, 18 Nov 2003, Andrew Morton wrote: > Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote: > > > > I've walked that code and can't see anything wrong anywhere. > > fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split > enabled. The exact same kernel runs fine on my other test boxes. But i really don't have faith in this compiler, it's the same one which constantly seems to be tripping into various problems. > Have you tried a different compiler? I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only unique thing about this hardware compared ot the other stuff i have here is that it's an AMD K6. Everything else is Intel. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops 2003-11-19 6:50 ` Zwane Mwaikambo @ 2003-11-19 7:24 ` Linus Torvalds 0 siblings, 0 replies; 52+ messages in thread From: Linus Torvalds @ 2003-11-19 7:24 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Andrew Morton, jon, linux-kernel On Wed, 19 Nov 2003, Zwane Mwaikambo wrote: > > I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only > unique thing about this hardware compared ot the other stuff i have here > is that it's an AMD K6. Everything else is Intel. Different TLB sizes (and organizations) etc can _easily_ matter, if the Intel one just happens to work because something stays in the TLB while the page table mapping is incorrect and keeps the system afloat. Or - and in this case more likely - since the problem is fixed by running a (complex) thing that trashes all over the DTLB/ITLB, it's more likely that there might be a _missing_ TLB invalidate somewhere, and that the Intel boxes stay up because they have a smaller TLB and the stale entry gets flushed out early from them. But you already tried a "flush_tlb_all()" which _should_ have flushed absolutely everything, including global tables. I dunno. It could be hitting a CPU bug too, of course. It would be interesting to hear if other K6 users see problems.. Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2003-12-04 4:35 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-13 7:30 2.6.0-test9-mm3 Andrew Morton 2003-11-13 20:03 ` [PATCH] linux-2.6.0-test9-mm3_verbose-timesource-acpi-pm_A0 john stultz 2003-11-13 22:03 ` 2.6.0-test9-mm3 - AIO test results Daniel McNeil 2003-11-17 5:25 ` Suparna Bhattacharya 2003-11-18 1:15 ` Daniel McNeil 2003-11-18 1:37 ` Daniel McNeil 2003-11-18 11:55 ` Suparna Bhattacharya 2003-11-18 23:47 ` Daniel McNeil 2003-11-24 9:42 ` Suparna Bhattacharya 2003-11-25 23:49 ` [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch Daniel McNeil 2003-11-26 7:55 ` Suparna Bhattacharya 2003-12-02 1:35 ` Daniel McNeil 2003-12-02 15:25 ` Suparna Bhattacharya 2003-12-03 23:14 ` Daniel McNeil 2003-12-04 4:40 ` Suparna Bhattacharya 2003-11-13 22:04 ` 2.6.0-test9-mm3 (compile stats) John Cherry 2003-11-14 5:07 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 20:57 ` 2.6.0-test9-mm3 Zwane Mwaikambo 2003-11-14 21:57 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 21:37 ` 2.6.0-test9-mm3 Zwane Mwaikambo 2003-11-14 21:47 ` 2.6.0-test9-mm3 Linus Torvalds 2003-11-15 0:55 ` 2.6.0-test9-mm3 Zwane Mwaikambo 2003-11-15 19:34 ` [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Zwane Mwaikambo 2003-11-15 19:52 ` Zwane Mwaikambo 2003-11-17 21:46 ` Zwane Mwaikambo 2003-11-17 22:42 ` Linus Torvalds 2003-11-17 23:01 ` Zwane Mwaikambo 2003-11-17 23:14 ` Zwane Mwaikambo 2003-11-18 7:21 ` Zwane Mwaikambo 2003-11-18 15:47 ` Linus Torvalds 2003-11-18 16:16 ` Zwane Mwaikambo 2003-11-18 16:37 ` Linus Torvalds 2003-11-18 17:08 ` Zwane Mwaikambo 2003-11-18 17:38 ` Martin J. Bligh 2003-11-18 17:22 ` Zwane Mwaikambo 2003-11-19 20:32 ` Matt Mackall 2003-11-19 23:09 ` Matt Mackall 2003-11-20 7:14 ` Zwane Mwaikambo 2003-11-20 7:44 ` Matt Mackall 2003-11-20 7:53 ` Andrew Morton 2003-11-20 8:13 ` Matt Mackall 2003-11-14 19:08 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-14 18:59 ` 2.6.0-test9-mm3 Andrew Morton 2003-11-14 19:32 ` 2.6.0-test9-mm3 Mike Fedyk 2003-11-14 20:27 ` 2.6.0-test9-mm3 John Stoffel 2003-11-15 1:01 ` 2.6.0-test9-mm3 Mike Fedyk 2003-11-14 19:10 ` 2.6.0-test9-mm3 Badari Pulavarty 2003-11-14 20:29 ` 2.6.0-test9-mm3 Martin J. Bligh 2003-11-17 20:58 ` 2.6.0-test9-mm3 bill davidsen 2003-11-18 23:48 Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Jon Foster 2003-11-19 3:24 ` Zwane Mwaikambo 2003-11-19 5:45 ` Andrew Morton 2003-11-19 6:50 ` Zwane Mwaikambo 2003-11-19 7:24 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).