ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
in evaluating the stability, efficacy and relative performance of Nick's
work.
We're looking for feedback on the subjective behaviour and on the usual
server benchmarks please.
. Random other stuff.
Changes since 2.6.0-test4-mm4:
linus.patch
Latest from Linus
-handle-unreadable-dot-config.patch
-huge-net-update.patch
-disable-athlon-prefetch.patch
-sis900-atomicity-fix.patch
-x86_64-update-3.patch
-random-locking-fixes.patch
-random-accounting-and-sleeping-fixes.patch
-yenta-20030817-1-zv.patch
-yenta-20030817-2-override.patch
-yenta-20030817-3-sockinit.patch
-yenta-20030817-4-pm.patch
-yenta-20030817-5-pm2.patch
-yenta-20030817-6-init.patch
-yenta-20030817-7-quirks.patch
-proc-pid-setuid-ownership-fix.patch
-pid-revalidate-security-hook.patch
-dac960-GAM-IOCTLs-cleanup.patch
-kj-maintainers.patch
-ide-docs-update.patch
-v4l-use-after-free-fix.patch
-ikconfig-makefile-update.patch
-ftape-warning-fix.patch
-jffs-retval-fix.patch
-make-ACPI_SLEEP-select-SOFTWARE_SUSPEND.patch
-3GB-personality.patch
-zeromap_pmd_range-fix.patch
-no-async-write-errors-on-close.patch
-sis190-fix.patch
-remove-add_wait_queue_cond.patch
-spin_lock_irqrestore-fixes.patch
-pcmciamtd-fix.patch
-zoran-memleak-fixes.patch
-zoran-rename-debug.patch
-zoran-release-callback.patch
-zoran-pci_disable_device.patch
-zoran-cleanups.patch
-zoran-cleanups-2.patch
-zoran-naming-fix.patch
-airo-build-fix.patch
-m68k-vmlinux_lds-move.patch
-mac-ide-fix.patch
-m68k-asm-sections-fix.patch
-m68k-asm-local.patch
-amiga-z2ram-fix.patch
-amiga-floppy-fix.patch
-atari-floppy-fix.patch
-m68k-switch_to-fix.patch
-pcxx-warning-fix.patch
-pcnet32-unregister_pci-fix.patch
-hwifs-oops-unregister-fix.patch
-c99-conversions.patch
-cyc2x-fixes.patch
-noacpi-option-fix.patch
-h8300-interrupt-fix.patch
-proc-kallsyms-caching-fix.patch
-proc-kallsyms-permission-fix.patch
-cu3088-string-null-termination-fix.patch
-kobject-doc-addition.patch
-vm_enough_memory-speedup.patch
-abi-doc-update.patch
-remove-bio-boot-messages.patch
-ni5010-build-fix.patch
-sis190-build-fix.patch
-nopage-fix.patch
-parport_pc-rmmod-oops-fix.patch
-reiserfs-writepage-fix.patch
-visws-build-fix.patch
-cciss-queue-init-fix.patch
-htree-big-endian-fix.patch
-selinux-file-fcntl-fix.patch
-selinux-avtab-fix.patch
-selinux-format-specifiers-fix.patch
-selinux-binprm-hooks-rework.patch
-ext2-xattr-typo-fix.patch
-bad-inode-ops.patch
-kcore-aout-build-fix.patch
-nfs4proc-warnings-fix.patch
-bluetooth-warning-fixes.patch
-nopage-rss-accounting-fix.patch
-sonypi-update.patch
-meye-update.patch
-jbd-stfu.patch
-proc-pid-maps-32-bit-fix.patch
-acpi-pci-link-fix.patch
-rusage-context-switch-counters.patch
-rusage-context-switch-counters-fix.patch
-large-dev_t-01.patch
-large-dev_t-02.patch
-large-dev_t-03.patch
-large-dev_t-04.patch
-large-dev_t-05.patch
-large-dev_t-06.patch
-large-dev_t-07.patch
-large-dev_t-08.patch
-large-dev_t-09.patch
-large-dev_t-10.patch
-large-dev_t-11.patch
-large-dev_t-12.patch
-large-dev_t-12-fix.patch
-size_t-printk-warning-fixes.patch
-stallion-build-fix-2.patch
-evdev_ioctl-fix.patch
-as-no-initial-antic.patch
-hch-contacts-update.patch
-h8300-include-update.patch
-cyclades-isa-fix.patch
-old-module-tools-warning.patch
-old-module-tools-warning-fix.patch
-arcnet-printk-fix.patch
-floppy-cleanup.patch
-floppy-more-cleanup.patch
-v850-nommu-export-fixes.patch
-v850-RODATA-fix.patch
-dnotify-use-tgid.patch
-send_sigio-decl-fix.patch
-ipc-use-tgid.patch
-voyager-cpumask_t-fix.patch
-mtrr-attrib_to_str-consolidation.patch
-ioctl_end-fix.patch
-raw-driver-fixes.patch
-ipc_init-shuffle.patch
-zone-pressure-fixes.patch
-zone-pressure-simplification.patch
-remove-dead-sse-checks.patch
-hpet-01-late-time_init.patch
-hpet-02-boot-time-parsing.patch
-hpet-03-misc.patch
-hpet-03-misc-tweaks.patch
-hpet-04-core.patch
-hpet-05-timer-services.patch
-hpet-05-timer-services-tweaks.patch
-hpet-06-rtc-emulation.patch
-advansys-procfs-fix.patch
-usb-serial-oops-fix.patch
-handle-setup_swap_extents-error.patch
-aha1542-oops-fix.patch
-cosa-free_netdev-fix.patch
-tty_files-oops-fix.patch
-remove-kcore-aout.patch
Merged
-deadline-requeue-workaround.patch
Dropped: fixed properly.
-tdfx-build-fix.patch
Folded into fbdev.patch
+misc34.patch
Misc fixes
+cfq-3-fixes.patch
CFQ IO scheduler fix
+ide-pm-oops-fix.patch
IDE power management fix
+kobject-unlimited-name-lengths-use-after-free-fix.patch
kobject oops fix
+convert-proc-stat-to-seq_file.patch
Use seqfile for /proc/stat
+get_rtc_time-fix.patch
RTC-vs-HPET fixes
+ricoh-mask-fix.patch
PCMCIA fix
+visws-qla1280-needs-pio.patch
SCSI fix
+dac960-devfs_name-fix.patch
Fix devfs on DAC960
+ikconfig-gzipped.patch
Move the ikconfig info to /proc/config.gz
+flush-invalidate-fixes.patch
+flush-invalidate-fixes-warning-fix.patch
Lots of rework of the cache flushing API and code. From DaveM
+elv-insertion-fix.patch
IO scheduler fixes
+8250_acpi-taints-kernel.patch
Add copyright to 8250_acpi.c
+proc_misc-build-fix.patch
Compile fix
+slab-check-PG_slab.patch
More slab debugging
+ide_floppy-maybe-fix.patch
Try to mend ide_floppy
+might_sleep-improvements.patch
Extra atomicity debug work.
+MODULE_ALIAS-in-block-devices.patch
+MODULE_ALIAS-in-char-devices.patch
Module autoloading support
+unpercpuify-in_flight-counter.patch
microoptimise disk stats accumulation
+enable-selinux-with-boot-parameter.patch
SELinux requires "selinux" on the kernel boot command line
+pty-devfs-fix.patch
sort-of fix old-style pty's
+i8042-free_irq-fix.patch
i8042 IRQ management fixlet.
+reiserfs-direct-io.patch
direct-IO support for reiserfs
+pdflush-diag.patch
debug stuff
+netlink-warning-fixes.patch
Warnig fixes
+really-use-english-date-in-version-string.patch
Locale fixes for the kernel version string
+acpi-pci-routing-fixes.patch
ACPI fixes
+psmouse_ipms2-option.patch
Add psmouse_ipms2 module/boot parameter to force PS/2 IPMS2 protocol
+i8042-history.patch
Extra i8042 debug support
-sched-CAN_MIGRATE_TASK-fix.patch
-sched-balance-fix-2.6.0-test3-mm3-A0.patch
-sched-2.6.0-test2-mm2-A3.patch
-ppc-sched_clock.patch
-ppc64-sched_clock.patch
-sparc64_sched_clock.patch
-x86_64-sched_clock.patch
-sched-warning-fix.patch
-sched-balance-tuning.patch
-sched-no-tsc-on-numa.patch
-o12.2int.patch
-o12.3.patch
-o13int.patch
-o13.1int.patch
-o14int.patch
-o14int-div-fix.patch
-o14.1int.patch
-o15int.patch
-o16int.patch
-o16.1int.patch
-o16.2int.patch
-o16.3int.patch
-o18int.patch
-o18.1int.patch
-sched-cpu-migration-fix.patch
Dropped
+np-sched-01-sched-fork-cleanup.patch
+np-sched-02-sched-migrate-fix.patch
+np-sched-03-sched-balance-tuning.patch
+np-sched-04-sched-policy-10b.patch
Added.
-4g4g-preempt-vstack-fix.patch
-4g4g-kmap-warning-comments.patch
-4g4g-slab-__get_user-fix.patch
-4g4g-vmlinux-update-got-lost.patch
-4g4g-do_page_fault-cleanup.patch
-4g4g-cleanups.patch
-kgdb-4g4g-fix-2.patch
-4g4g-config-fix.patch
-4g4g-pmd-fix.patch
-4g4g-wli-fixes.patch
-4g4g-fpu-fix.patch
-4g4g-show_registers-fix.patch
-4g4g-pin_page-atomicity-fix.patch
-4g4g-remove-touch_all_pages.patch
-4g4g-debug-flags-fix.patch
-4g4g-TI_task-fix.patch
-cyclone-fixmap-fix.patch
Folded into 4g-2.6.0-test2-mm2-A5.patch
All 141 patches
linus.patch
mm.patch
add -mmN to EXTRAVERSION
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning 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
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-build-fixes.patch
Fix ppc64 breakage
ppc64-bar-0-fix.patch
Allow PCI BARs that start at 0
ppc64-reloc_hide.patch
ppc64-semaphore-reimplementation.patch
ppc64: use the ia32 semaphore implementation
ppc64-local.patch
ppc64: local.h implementation
sym-do-160.patch
make the SYM driver do 160 MB/sec
rt-tasks-special-vm-treatment.patch
real-time enhanced page allocator and throttling
rt-tasks-special-vm-treatment-2.patch
input-use-after-free-checks.patch
input layer debug checks
fbdev.patch
framebbuffer driver update
cursor-flashing-fix.patch
fbdev: fix cursor letovers
misc34.patch
misc fixes
slab-hexdump.patch
slab: hexdump structures when things go wrong
aic7xxx-parallel-build-fix.patch
fix parallel builds for aic7xxx
thread-pgrp-fix-2.patch
Fix setpgid and threads
ramdisk-cleanup.patch
delay-ksoftirqd-fallback.patch
Try harded in IRQ context before falling back to ksoftirqd
intel8x0-cleanup.patch
intel8x0 cleanups
claim-serio-early.patch
Serio: claim serio early
fix-strange-code-in-bio_add_page.patch
Fix odd code in bio_add_page
mark-devfs-obsolete.patch
mark devfs obsolete
cfq-3.patch
CFQ io scheduler
cfq-3-fixes.patch
CFQ fixes
sysfs-memleak-fix.patch
Fix sysfs memory leak
VT8231-router-detection.patch
VT8231 IRQ router detection
block-devfs-conversions.patch
Initialise devfs_name in various block drivers
test4-pm1.patch
power management update
ide-pm-oops-fix.patch
IDE power management oops fix
kobject-unlimited-name-lengths.patch
kobject: Support unlimited name lengths.
kobject-unlimited-name-lengths-use-after-free-fix.patch
kobject_cleanup() use-after-free-fix
convert-proc-stat-to-seq_file.patch
convert /proc/stat to seq_file
get_rtc_time-fix.patch
Fix rtc symbol clash and HPET config problems
ricoh-mask-fix.patch
pcmcia: ricoh.h mask fix
EDEC
From: KOMURO <[email protected]>, Alan Cox <[email protected]>
RL5C4XX_16BIT_MEM_0 was wrong.
visws-qla1280-needs-pio.patch
add config option for qla1280 SCSI MMIO/ioport selection
dac960-devfs_name-fix.patch
dac960 devfs_name initialisation fix
ikconfig-gzipped.patch
Move ikconfig to /proc/config.gz
flush-invalidate-fixes.patch
memory writeback/invalidation fixes
flush-invalidate-fixes-warning-fix.patch
elv-insertion-fix.patch
elevator insertion fixes
8250_acpi-taints-kernel.patch
8250_acpi taints kernel
proc_misc-build-fix.patch
proc_misc.c needs irq.h
slab-check-PG_slab.patch
more slab page checking
ide_floppy-maybe-fix.patch
might fix ide_floppy
might_sleep-improvements.patch
might_sleep() improvements
MODULE_ALIAS-in-block-devices.patch
MODULE_ALIAS() in block devices
MODULE_ALIAS-in-char-devices.patch
MODULE_ALIAS() in char devices
unpercpuify-in_flight-counter.patch
Remove percpufication of in_flight counter in diskstats
enable-selinux-with-boot-parameter.patch
Enable SELinux via boot parameter
pty-devfs-fix.patch
devfs pty fix
i8042-free_irq-fix.patch
i8042 free_irq() aliasing fix
reiserfs-direct-io.patch
resierfs direct-IO support
pdflush-diag.patch
netlink-warning-fixes.patch
really-use-english-date-in-version-string.patch
really use english date in version string
acpi-pci-routing-fixes.patch
Fixing USB interrupt problems with ACPI enabled
p00001_synaptics-restore-on-close.patch
p00002_psmouse-reset-timeout.patch
p00003_synaptics-multi-button.patch
p00004_synaptics-optional.patch
p00005_synaptics-pass-through.patch
p00006_psmouse-suspend-resume.patch
p00007_synaptics-old-proto.patch
synaptics-mode-set.patch
Synaptics mode setting
syn-multi-btn-fix.patch
synaptics multibutton fix
keyboard-resend-fix.patch
keyboard resend fix
psmouse_ipms2-option.patch
Force mouse detection as imps/2 (and fix my KVM switch)
i8042-history.patch
debug: i8042 history dumping
linux-isp-2.patch
linux-isp-2-fix-again.patch
lost feral fix
feral-bounce-fix.patch
Feral driver - highmem issues
feral-bounce-fix-2.patch
Feral driver bouncing fix
list_del-debug.patch
list_del debug check
print-build-options-on-oops.patch
print a few config options on oops
show_task-free-stack-fix.patch
show_task() fix and cleanup
put_task_struct-debug.patch
ia32-mknod64.patch
mknod64 for ia32
ext2-64-bit-special-inodes.patch
ext2: support for 64-bit device nodes
ext3-64-bit-special-inodes.patch
ext3: support for 64-bit device nodes
64-bit-dev_t-kdev_t.patch
64-bit dev_t and kdev_t
64-bit-dev_t-other-archs.patch
enable 64-bit dev_t for other archs
mknod64-64-bit-fix.patch
dev_t: fix mknod for 64-bit archs
ustat64.patch
ustat64
ppc-64-bit-stat.patch
fix ppc stat.h for 64-bit dev_t
64-bit-dev_t-init_rd-fixes.patch
initrd fixes for 64-bit dev_t
arch-dev_t-stat-fixes.patch
Fix all asm-*/stat.h dev_t instances
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
sparc64-lockmeter-fix.patch
sparc64-lockmeter-fix-2.patch
Fix lockmeter on sparc64
printk-oops-mangle-fix.patch
disentangle printk's whilst oopsing on SMP
20-odirect_enable.patch
21-odirect_cruft.patch
22-read_proc.patch
23-write_proc.patch
24-commit_proc.patch
25-odirect.patch
nfs-O_DIRECT-always-enabled.patch
Force CONFIG_NFS_DIRECTIO
np-sched-01-sched-fork-cleanup.patch
move fork-related code to fork.c
np-sched-02-sched-migrate-fix.patch
scheduler migration fix
np-sched-03-sched-balance-tuning.patch
scheduler balancing tuning
np-sched-04-sched-policy-10b.patch
scheduler policy changes
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
ppc-fixes.patch
make mm4 compile on ppc
aic7xxx_old-oops-fix.patch
aio-01-retry.patch
AIO: Core retry infrastructure
io_submit_one-EINVAL-fix.patch
Fix aio process hang on EINVAL
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
aio-05-fs_write.patch
AIO: Filesystem aio write
aio-05-fs_write-fix.patch
aio-06-bread_wq.patch
AIO: Async block read
aio-06-bread_wq-fix.patch
aio-07-ext2getblk_wq.patch
AIO: Async get block for ext2
O_SYNC-speedup-2.patch
speed up O_SYNC writes
aio-09-o_sync.patch
aio O_SYNC
aio-10-BUG-fix.patch
AIO: fix a BUG
aio-11-workqueue-flush.patch
AIO: flush workqueues before destroying ioctx'es
aio-12-readahead.patch
AIO: readahead fixes
aio-dio-no-readahead.patch
aio O_DIRECT no readahead
lock_buffer_wq-fix.patch
lock_buffer_wq fix
unuse_mm-locked.patch
AIO: hold the context lock across unuse_mm
aio-take-task_lock.patch
From: Suparna Bhattacharya <[email protected]>
Subject: Re: 2.5.72-mm1 - Under heavy testing with AIO,.. vmstat seems to blow the kernel
aio-O_SYNC-fix.patch
Unify o_sync changes for aio and regular writes
aio-O_SYNC-fix-missing-bit.patch
aio-O_SYNC-fix bits got lost
O_SYNC-speedup-nolock-fix.patch
aio-writev-nsegs-fix.patch
aio: writev nr_segs fix
aio-remove-lseek-triggerable-BUG_ONs.patch
aio-readahead-rework.patch
Unified page range readahead for aio and regular reads
aio-readahead-speedup.patch
Readahead issues and AIO read speedup
aio-osync-fix-2.patch
More AIO O_SYNC related fixes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How is the work on CPU scheduler selection coming along? It would be a
Good Thing (TM) to have in this one imho.
- --
Christan Axelsson
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/VZV5yqbmAWw8VdkRAvr1AJ4mEWvJJg2S8jIMk5OOBx+/kHmgtACg4CG2
YLVDbf13vBtm6uFNoQUZG3M=
=81tT
-----END PGP SIGNATURE-----
I got the following compile error (using gcc 2.95) in 2.6.0-test4-mm5
(but it seems to come from Linus' tree):
<-- snip -->
...
CC [M] drivers/net/sungem.o
drivers/net/sungem.c:2444: duplicate initializer
drivers/net/sungem.c:2444: (near initialization for `gem_ethtool_ops.get_link')
make[2]: *** [drivers/net/sungem.o] Error 1
<-- snip -->
It seems gcc is right, there are two .get_link members in this struct:
<-- snip -->
...
static struct ethtool_ops gem_ethtool_ops = {
.get_drvinfo = gem_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_settings = gem_get_settings,
.set_settings = gem_set_settings,
.nway_reset = gem_nway_reset,
.get_link = gem_get_link,
.get_msglevel = gem_get_msglevel,
.set_msglevel = gem_set_msglevel,
};
...
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> As a tangent, gem_pcs_interrupt appears to call netif_carrier_xxx but
> not set gem->lstate. David/Ben, is that a bug?
Looks like it is, David, you are the one who knows the PCS stuff ...
BTW. David: Any reason why you wouldn't let me change all occurences
of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
I don't like force re-enabling interrupts the way we do it now with
spin_unlock_irq() the way we do it now. Among other things, that
breaks SA_INTERRUPT semantics and that breaks some pet project of
mine which is to run the IRQ handler with interrupts off when the
kernel stack is below a given threshold (to limit interrupt depth)
Ben.
===== drivers/net/sungem.c 1.44 vs edited =====
--- 1.44/drivers/net/sungem.c Sun Aug 24 08:58:18 2003
+++ edited/drivers/net/sungem.c Wed Sep 3 12:28:30 2003
@@ -2416,13 +2416,6 @@
return 0;
}
-static u32 gem_get_link(struct net_device *dev)
-{
- struct gem *gp = dev->priv;
-
- return (gp->lstate == link_up);
-}
-
static u32 gem_get_msglevel(struct net_device *dev)
{
struct gem *gp = dev->priv;
@@ -2441,7 +2434,6 @@
.get_settings = gem_get_settings,
.set_settings = gem_set_settings,
.nway_reset = gem_nway_reset,
- .get_link = gem_get_link,
.get_msglevel = gem_get_msglevel,
.set_msglevel = gem_set_msglevel,
};
The following compile error (tested with gcc 2.95) seems to come from
Linus' tree:
<-- snip -->
...
CC [M] drivers/scsi/imm.o
In file included from drivers/scsi/imm.c:55:
drivers/scsi/imm.h:105: duplicate array index in initializer
drivers/scsi/imm.h:105: (near initialization for `IMM_MODE_STRING')
make[2]: *** [drivers/scsi/imm.o] Error 1
<-- snip -->
The problem is the following code in imm.h (with
CONFIG_SCSI_IZIP_EPP16 enabled):
<-- snip -->
...
static char *IMM_MODE_STRING[] =
{
[IMM_AUTODETECT] = "Autodetect",
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
[IMM_EPP_16] = "EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_16] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
[IMM_UNKNOWN] = "Unknown",
};
...
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 03, 2003 at 09:17:13AM +0200, Christian Axelsson wrote:
> How is the work on CPU scheduler selection coming along? It would be a
> Good Thing (TM) to have in this one imho.
No idea if anyone's doing it, but it should be relatively easy to do.
-- wli
El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <[email protected]> escribi?:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
> We're looking for feedback on the subjective behaviour and on the usual
> server benchmarks please.
I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
skips that didn't happened before, big pauses in X...gcc starves anything else.
-mm4 was better there.
Benjamin Herrenschmidt wrote:
> BTW. David: Any reason why you wouldn't let me change all occurences
> of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
IMO... even though you do lose a tiny bit of performance, I definitely
prefer the save/restore versions.
It allows the arch a lot more flexibility, so I even have a [weak]
argument that {save,restore} variants increase portability. And it's
safer, as I like to avoid code which winds up doing (as it passes
through layers) spin_unlock_irq() followed by spin_unlock_irqrestore().
Jeff
On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
CHK include/linux/compile.h
CC drivers/acpi/pci_link.o
drivers/acpi/pci_link.c: In function `acpi_pci_link_try_get_current':
drivers/acpi/pci_link.c:290: error: `_dbg' undeclared (first use in this function)
drivers/acpi/pci_link.c:290: error: (Each undeclared identifier is reported only once
drivers/acpi/pci_link.c:290: error: for each function it appears in.)
make[2]: *** [drivers/acpi/pci_link.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
------------------------------------------------------------------------------------------
bill
On Thu, Sep 04, 2003 at 01:08:52AM +0200, Diego Calleja Garc?a wrote:
> El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <[email protected]> escribi?:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
> >
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of Nick's
> > work.
> >
> > We're looking for feedback on the subjective behaviour and on the usual
> > server benchmarks please.
>
>
> I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
> skips that didn't happened before, big pauses in X...gcc starves anything else.
> -mm4 was better there.
Can you put your Xserver back to nice -10, and try again?
Sorry, that patch was intended for broader tests before we check it out.
As some people pointed out, it needs:
int result;
+
+ ACPI_FUNCTION_TRACE("acpi_pci_link_try_get_current");
+
result = acpi_pci_link_get_current(link);
if (result && link->irq.active) {
return_VALUE(result);
}
> -----Original Message-----
> From: Bill Huey (hui) [mailto:[email protected]]
> Sent: Wednesday, September 03, 2003 6:31 PM
> To: Andrew Morton
> Cc: [email protected]; Bill Huey (hui)
> Subject: Re: 2.6.0-test4-mm5
>
> On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-
> test4/2.6.0-test4-mm5/
>
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
> CHK include/linux/compile.h
> CC drivers/acpi/pci_link.o
> drivers/acpi/pci_link.c: In function `acpi_pci_link_try_get_current':
> drivers/acpi/pci_link.c:290: error: `_dbg' undeclared (first use in
this
> function)
> drivers/acpi/pci_link.c:290: error: (Each undeclared identifier is
> reported only once
> drivers/acpi/pci_link.c:290: error: for each function it appears in.)
> make[2]: *** [drivers/acpi/pci_link.o] Error 1
> make[1]: *** [drivers/acpi] Error 2
> make: *** [drivers] Error 2
>
>
------------------------------------------------------------------------
--
> ----------------
>
> bill
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
* Bill Huey ([email protected]) wrote:
> On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
> CHK include/linux/compile.h
> CC drivers/acpi/pci_link.o
> drivers/acpi/pci_link.c: In function `acpi_pci_link_try_get_current':
> drivers/acpi/pci_link.c:290: error: `_dbg' undeclared (first use in this function)
> drivers/acpi/pci_link.c:290: error: (Each undeclared identifier is reported only once
> drivers/acpi/pci_link.c:290: error: for each function it appears in.)
> make[2]: *** [drivers/acpi/pci_link.o] Error 1
> make[1]: *** [drivers/acpi] Error 2
> make: *** [drivers] Error 2
try the patch below.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--- drivers/acpi/pci_link.c.try Wed Sep 3 15:06:33 2003
+++ drivers/acpi/pci_link.c Wed Sep 3 15:07:22 2003
@@ -285,6 +285,8 @@ acpi_pci_link_try_get_current (
{
int result;
+ ACPI_FUNCTION_TRACE("acpi_pci_link_try_get_current");
+
result = acpi_pci_link_get_current(link);
if (result && link->irq.active) {
return_VALUE(result);
Mike Fedyk wrote:
>On Thu, Sep 04, 2003 at 01:08:52AM +0200, Diego Calleja Garc?a wrote:
>
>>El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <[email protected]> escribi?:
>>
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>>>
>>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>>> in evaluating the stability, efficacy and relative performance of Nick's
>>> work.
>>>
>>> We're looking for feedback on the subjective behaviour and on the usual
>>> server benchmarks please.
>>>
>>
>>I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
>>skips that didn't happened before, big pauses in X...gcc starves anything else.
>>-mm4 was better there.
>>
>
>Can you put your Xserver back to nice -10, and try again?
>
This would help X, but regardless mp3 playing should not skip. I think its
giving newly forked children much too high a priority. Basically new
children
can't get less than 50% sleep time, which is stupid on my behalf because a
program which continually forks children that do a little bit of work then
exit would basically be at 50% sleep time when it should be at or close
to 0.
On Wed, 03 Sep 2003 12:32:41 -0400
Jeff Garzik <[email protected]> wrote:
> David, would you look over this patch and apply/modify?
Applied, thanks Jeff.
> I would prefer to use the generic ethtool_op_get_link, because (a)
> sungem is already using netif_carrier_xxx, and (b) if ->get_link ever
> returns an incorrect value, that signals a netif_carrier_xxx bug exists.
Agreed.
> As a tangent, gem_pcs_interrupt appears to call netif_carrier_xxx but
> not set gem->lstate. David/Ben, is that a bug?
Doesn't really matter, I don't think the rest of the PCS code even
cares about the setting of gem-lstate.
Diego Calleja Garc?a wrote:
>El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <[email protected]> escribi?:
>
>
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>>
>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>> in evaluating the stability, efficacy and relative performance of Nick's
>> work.
>>
>> We're looking for feedback on the subjective behaviour and on the usual
>> server benchmarks please.
>>
>>
>
>
>I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
>skips that didn't happened before, big pauses in X...gcc starves anything else.
>-mm4 was better there.
>
>
Hmm... what's heavy gcc load?
On Thu, 2003-09-04 at 01:31, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > BTW. David: Any reason why you wouldn't let me change all occurences
> > of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
>
>
> IMO... even though you do lose a tiny bit of performance, I definitely
> prefer the save/restore versions.
I'm not even sure you actually lose perfs... at least on ppc ;)
Ben.
On Tue, 2 Sep 2003 23:18:12 -0700
Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
[ snip. ]
Getting this one when setting dma on a barracuda SATA ST380013AS, i875 chipset.
Sep 4 09:53:26 pyro kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel: hde: channel busy
Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
Sep 4 09:53:26 pyro kernel: hde: timeout waiting for DMA
Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel:
Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel:
Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
On Thu, 4 Sep 2003 10:29:18 -0400
"Bruno T. Moura" <[email protected]> wrote:
> On Tue, 2 Sep 2003 23:18:12 -0700
> Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
> >
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of Nick's
> > work.
> >
> [ snip. ]
>
> Getting this one when setting dma on a barracuda SATA ST380013AS, i875 chipset.
>
> Sep 4 09:53:26 pyro kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel: hde: channel busy
> Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
> Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
> Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
> Sep 4 09:53:26 pyro kernel: hde: timeout waiting for DMA
> Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel:
> Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
> Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel:
> Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
>
forgot this log part :
Sep 4 09:53:26 pyro kernel: ide2: reset: success
Sep 4 09:53:26 pyro kernel: hde: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
Sep 4 09:53:26 pyro kernel: hde: task_no_data_intr: error=0x04 { DriveStatusError }
Sep 4 09:53:26 pyro kernel: blk: queue 41d72600, I/O limit 4095Mb (mask 0xffffffff)
Em Wed, Sep 03, 2003 at 07:02:56PM +0200, Adrian Bunk escreveu:
> The following compile error (tested with gcc 2.95) seems to come from
> Linus' tree:
>
> <-- snip -->
>
> ...
> CC [M] drivers/scsi/imm.o
> In file included from drivers/scsi/imm.c:55:
> drivers/scsi/imm.h:105: duplicate array index in initializer
> drivers/scsi/imm.h:105: (near initialization for `IMM_MODE_STRING')
> make[2]: *** [drivers/scsi/imm.o] Error 1
>
> <-- snip -->
>
> The problem is the following code in imm.h (with
> CONFIG_SCSI_IZIP_EPP16 enabled):
>
> <-- snip -->
>
> ...
> static char *IMM_MODE_STRING[] =
> {
> [IMM_AUTODETECT] = "Autodetect",
> [IMM_NIBBLE] = "SPP",
> [IMM_PS2] = "PS/2",
> [IMM_EPP_8] = "EPP 8 bit",
> [IMM_EPP_16] = "EPP 16 bit",
> #ifdef CONFIG_SCSI_IZIP_EPP16
> [IMM_EPP_16] = "EPP 16 bit",
> #else
> [IMM_EPP_32] = "EPP 32 bit",
> #endif
> [IMM_UNKNOWN] = "Unknown",
> };
> ...
>
> <-- snip -->
Original code was:
static char *IMM_MODE_STRING[] =
{
"Autodetect",
"SPP",
"PS/2",
"EPP 8 bit",
"EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
"EPP 16 bit",
#else
"EPP 32 bit",
#endif
"Unknown"};
I just converted it to the more safe c99 init style, but haven't noticed
the original bug, that is "EPP 16 bit" was duplicated... But this is already
fixed by Andrew Morton on current Linus bk tree.
Thanks Andrew for fixing, Adrian for noticing.
- Arnaldo
On Thu, 2003-09-04 10:30:56 -0300, Arnaldo Carvalho de Melo <[email protected]>
wrote in message <[email protected]>:
> Em Wed, Sep 03, 2003 at 07:02:56PM +0200, Adrian Bunk escreveu:
> > The following compile error (tested with gcc 2.95) seems to come from
> > Linus' tree:
>
> I just converted it to the more safe c99 init style, but haven't noticed
C99 style is
.element = initializer,
not
[element] = initializer,
which is a GNU/GCCism.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Thu, Sep 04, 2003 at 03:52:56PM +0200, Jan-Benedict Glaw wrote:
> C99 style is
>
> .element = initializer,
>
> not
> [element] = initializer,
>
> which is a GNU/GCCism.
We're talking about arrays here..
.element obviously never works for arrays and [constant] never
works for structs..
On Thu, 2003-09-04 15:30:23 +0100, Christoph Hellwig <[email protected]>
wrote in message <[email protected]>:
> On Thu, Sep 04, 2003 at 03:52:56PM +0200, Jan-Benedict Glaw wrote:
> > C99 style is
> >
> > .element = initializer,
> >
> > not
> > [element] = initializer,
> >
> > which is a GNU/GCCism.
>
> We're talking about arrays here..
*plonk* I stand corrected... I'm sorry...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Thu, Sep 04, 2003 at 10:30:56AM -0300, Arnaldo Carvalho de Melo wrote:
>...
> I just converted it to the more safe c99 init style, but haven't noticed
> the original bug, that is "EPP 16 bit" was duplicated... But this is already
> fixed by Andrew Morton on current Linus bk tree.
>
> Thanks Andrew for fixing, Adrian for noticing.
Andrews patch removed the first IMM_EPP_16 line in the array.
This isn't correct especially in the !CONFIG_SCSI_IZIP_EPP16 case,
reading all uses of this array (IMM_MODE_STRING is used to print the
corresponding string in printks).
If I'm not misunderstanding it, CONFIG_SCSI_IZIP_EPP16 means "use 16bit
even when 32bit is requested".
It seems the right solution is
static char *IMM_MODE_STRING[] =
{
[IMM_AUTODETECT] = "Autodetect",
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
[IMM_EPP_16] = "EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_32] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
[IMM_UNKNOWN] = "Unknown",
};
A patch against the current BK tree is below.
> - Arnaldo
cu
Adrian
--- linux-2.6.0-test4/drivers/scsi/imm.h.old 2003-09-04 19:47:23.000000000 +0200
+++ linux-2.6.0-test4/drivers/scsi/imm.h 2003-09-04 19:48:05.000000000 +0200
@@ -100,8 +100,9 @@
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
-#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_16] = "EPP 16 bit",
+#ifdef CONFIG_SCSI_IZIP_EPP16
+ [IMM_EPP_32] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <[email protected]> escribi?:
> Hmm... what's heavy gcc load?
make -j25 with 256 MB RAM.
My X server is reniced at -1; but reniced X to -10 and it didn't helped;
-j15 was better (less swapping) but still I saw various mp3 & mouse skips.
On Thu, Sep 04, 2003 at 08:23:19PM +0200, Diego Calleja Garc?a wrote:
> El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <[email protected]> escribi?:
>
> > Hmm... what's heavy gcc load?
>
> make -j25 with 256 MB RAM.
>
> My X server is reniced at -1; but reniced X to -10 and it didn't helped;
> -j15 was better (less swapping) but still I saw various mp3 & mouse skips.
And this worked good with Con's scheduler?
Try both schedulers on the same base (test4), and see if you see similair
differences.
I doubt it's the scheduler that's causing this problem. Once you get into
swap like that, the scheduler shouldn't affect it too much...
On Iau, 2003-09-04 at 15:29, Bruno T. Moura wrote:
> Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
> Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
> Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
SATA mode on the ICH5 really wants to be driven by Jeff Garziks libata
SATA drivers not the ide layer code. The IDE code doesnt currently know
about cable detect not being valid on the SATA ports.
Martin Schlemmer wrote:
>On Thu, 2003-09-04 at 20:23, Diego Calleja Garc?a wrote:
>
>>El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <[email protected]> escribi?:
>>
>>
>>>Hmm... what's heavy gcc load?
>>>
>>make -j25 with 256 MB RAM.
>>
>>My X server is reniced at -1; but reniced X to -10 and it didn't helped;
>>-j15 was better (less swapping) but still I saw various mp3 & mouse skips.
>>-
>>
>
>Without trying to be insulting, don't you think that you might
>be expecting too much ? I have a P4-2.4C (HT) on a i785 board
>with 1GB DDR400 memory running dual channel, and if I run two
>or three compile jobs at -j12 (more for testing Nick/Con's stuff,
>usually use -j[46] and never really more than 2 of 3 of them), I
>
I think Martin is right here. I don't know what would be a good reason
for wanting X to work nicely with a make -j25 running. X typically
needs at least 75% CPU on my box to be nicely interactive when moving
a window or scrolling something complex. This gives only 1% to each
cc1.
I am still working on my scheduler. I've removed backboost. It is
hypocritical of me to worry about complexity or difficult traceability
of say Con's implementation when backboost is probably "worse" than
anything he has ;)
So I've found I'm getting more consistent behaviour, but it is now
very dependant on nice to get X running well under load. I'm
concentrating on getting it working well with make -j <= 6.
On Thu, 2003-09-04 at 20:23, Diego Calleja Garc?a wrote:
> El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <[email protected]> escribi?:
>
> > Hmm... what's heavy gcc load?
>
> make -j25 with 256 MB RAM.
>
> My X server is reniced at -1; but reniced X to -10 and it didn't helped;
> -j15 was better (less swapping) but still I saw various mp3 & mouse skips.
> -
Without trying to be insulting, don't you think that you might
be expecting too much ? I have a P4-2.4C (HT) on a i785 board
with 1GB DDR400 memory running dual channel, and if I run two
or three compile jobs at -j12 (more for testing Nick/Con's stuff,
usually use -j[46] and never really more than 2 of 3 of them), I
do not expect everything to be blazing fast. Yes, while it is
not swapping (rare if ever do swap), I do expect xmms not to
skip, I do not expect the mouse to jerk, and yes I do expect
changing desktops to be fairly smooth and responsive. I do not
however expect apps to still start with the same speed, or doing
the "window wiggle thing" to still be 100% smooth.
Nick's stuff with X reniced to -10 do fix the "window wiggle"
issue as far as I am concerned, as it is relative smooth (not
croaking like in vanilla), although not 100% as great as Con's,
but then Nick's finish the two make jobs at -j12 faster than
Con's stuff, and fairly close to vanilla (yes not 100% scientific),
and that is what I expect, even though it is a fairly ok machine.
Point I want to make, is that yes, for desktop you want you xmms
to not skip, you window switching to be ok while compiling a new
kernel at make -j[246], but come on, this is like expecting a
mini to out drag a F1 car because you fitted it with a turbo.
Especially when you start to swap heavily, you cannot really
expect the system to be responsive, especially when it is something
that needs to access memory that is swapped, or need to come out
of free swap, or that need to access the disk.
Con/Nick do need feedback, but really, expecting the scheduler to
be nice while your disk/memory is thrashing and whatever also need
a slice of that pie. Can we try to keep it real ?
Thanks,
--
Martin Schlemmer
El Sat, 06 Sep 2003 02:17:22 +1000 Nick Piggin <[email protected]> escribi?:
[chaging email to avoid smart spam detectors]
> I think Martin is right here. I don't know what would be a good reason
> for wanting X to work nicely with a make -j25 running. X typically
> needs at least 75% CPU on my box to be nicely interactive when moving
> a window or scrolling something complex. This gives only 1% to each
> cc1.
I know; obiously it has not sense to ask that people makes -j25
smooth here; there's no way of doing that (with gcc 3.x :)
I just pointed out that -mm4 was a bit better under that load, specially
mp3 skips.
> So I've found I'm getting more consistent behaviour, but it is now
> very dependant on nice to get X running well under load. I'm
> concentrating on getting it working well with make -j <= 6.
I just hope 2.6 is shipped with a "decent" scheduler. Mp3 players are
probably the most important apps nowadays :P
On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
>...
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
> We're looking for feedback on the subjective behaviour and on the usual
> server benchmarks please.
>...
Short story:
I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
problems
Long story:
System:
K6-2 @ 500 MHz
128 MB RAM
1 GB swap
Debian unstable
Workload:
XFree86
FVWM
XMMS
Wine running "Master of Orion 2" (a round based space strategy game)
With 2.4 kernels and 2.5.72 everything works fine.
With 2.6.0-test? and 2.6.0-test?-mm? kernels up to 2.6.0-test4-mm4 the
XMMS sound sometimes skips or sounds slow (like when wou manually retard
a record). That's much more awful than skips.
RAM usage is low, even after a "swapoff -a" at about half of my RAM
would be enough.
The problems might be related to the fact that after I start Wine three
wine.bin processes run and each of them tries to get as much CPU time as
possible.
It might be part of the problem that although Wine is the interactive
task a working XMMS is subjectively more important.
With 2.6.0-test4-mm5 these problems don't occur. Instead, Wine feels
slow. I couldn;t test it much since after the first fast mouse movement
the X mouse cursor has lost the mouse cursor of the game (this might be
a bug in Wine, but it doesnt occur with other kernels).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
>On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
>
>>...
>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>> in evaluating the stability, efficacy and relative performance of Nick's
>> work.
>>
>> We're looking for feedback on the subjective behaviour and on the usual
>> server benchmarks please.
>>...
>>
>
>Short story:
>
>I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
>problems
>
>
>Long story:
>
>System:
>K6-2 @ 500 MHz
>128 MB RAM
>1 GB swap
>Debian unstable
>
>Workload:
>XFree86
>FVWM
>XMMS
>Wine running "Master of Orion 2" (a round based space strategy game)
>
>With 2.4 kernels and 2.5.72 everything works fine.
>
>With 2.6.0-test? and 2.6.0-test?-mm? kernels up to 2.6.0-test4-mm4 the
>XMMS sound sometimes skips or sounds slow (like when wou manually retard
>a record). That's much more awful than skips.
>
>RAM usage is low, even after a "swapoff -a" at about half of my RAM
>would be enough.
>
>The problems might be related to the fact that after I start Wine three
>wine.bin processes run and each of them tries to get as much CPU time as
>possible.
>
>It might be part of the problem that although Wine is the interactive
>task a working XMMS is subjectively more important.
>
>With 2.6.0-test4-mm5 these problems don't occur. Instead, Wine feels
>slow. I couldn;t test it much since after the first fast mouse movement
>the X mouse cursor has lost the mouse cursor of the game (this might be
>a bug in Wine, but it doesnt occur with other kernels).
>
>cu
>Adrian
>
Hi Adrian,
It would be great if you could test the latest mm kernel (mm6 as of now
I think), which has Con's latest stuff in it. You could also test my
newest scheduler patch. Thanks for the feedback.
On Sun, 7 Sep 2003 20:08, Adrian Bunk wrote:
> On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> >...
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of
> > Nick's work.
> >
> > We're looking for feedback on the subjective behaviour and on the usual
> > server benchmarks please.
> >...
>
> Short story:
>
> I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
> problems
What's your X and xmms nice values? Many X servers are reniced to -10 and some
shells spawn new apps at nice 5. After that the most common thing I find in
reports are upgrades to newer kernels losing hard disk dma at some stage (due
to config changes/movements) and it not being noticed.
Con
On Sun, Sep 07, 2003 at 10:18:27PM +1000, Con Kolivas wrote:
> On Sun, 7 Sep 2003 20:08, Adrian Bunk wrote:
> > On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> > >...
> > > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > > in evaluating the stability, efficacy and relative performance of
> > > Nick's work.
> > >
> > > We're looking for feedback on the subjective behaviour and on the usual
> > > server benchmarks please.
> > >...
> >
> > Short story:
> >
> > I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
> > problems
>
> What's your X and xmms nice values? Many X servers are reniced to -10 and some
They have both nice value 0.
> shells spawn new apps at nice 5. After that the most common thing I find in
> reports are upgrades to newer kernels losing hard disk dma at some stage (due
> to config changes/movements) and it not being noticed.
DMA is wrking without problems.
> Con
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Sep 07, 2003 at 08:39:14PM +1000, Nick Piggin wrote:
>
> Hi Adrian,
Hi Nick,
> It would be great if you could test the latest mm kernel (mm6 as of now
> I think), which has Con's latest stuff in it. You could also test my
> newest scheduler patch. Thanks for the feedback.
I didn't check -mm6 (I had a different problem with -mm6 and not that
much time).
I tried plain test4 with your sched-rollup-v14 and I got these awful
slower sound like when wou manually retard a record.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Sep 09, 2003 at 01:08:20AM +0200, Adrian Bunk wrote:
> On Sun, Sep 07, 2003 at 08:39:14PM +1000, Nick Piggin wrote:
> >
> > Hi Adrian,
>
> Hi Nick,
>
> > It would be great if you could test the latest mm kernel (mm6 as of now
> > I think), which has Con's latest stuff in it. You could also test my
> > newest scheduler patch. Thanks for the feedback.
>
> I didn't check -mm6 (I had a different problem with -mm6 and not that
> much time).
>
> I tried plain test4 with your sched-rollup-v14 and I got these awful
> slower sound like when wou manually retard a record.
More data:
I tried test5 and test5-mm1.
Both produced this awful slower sound like when wou manually retard a
record, although my subjective impression was that it happens fewer than
with test4 with your sched-rollup-v14.
2.5.72 is still better than all recent kernels I've tested... :-(
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed