* 2.5.74-mm1
@ 2003-07-03 9:37 Andrew Morton
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
` (8 more replies)
0 siblings, 9 replies; 90+ messages in thread
From: Andrew Morton @ 2003-07-03 9:37 UTC (permalink / raw)
To: linux-kernel, linux-mm
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
. Mainly a resync with various things and people. Plus a few fixlets.
. I dropped out a few patches which weren't really proving useful.
. Included Con's CPU scheduler changes. Feedback on the effectiveness of
this and the usual benchmarks would be interesting.
Changes to the CPU scheduler tend to cause surprising and subtle problems
in areas where you least expect it, and these do take a long time to
materialise. Alterations in there need to be made carefully and cautiously.
We shall see...
Changes since 2.5.73-mm3:
linus.patch
Latest Linus tree
-move_vma-VM_LOCKED-fix.patch
-e100-use-after-free-fix.patch
-3-unmap-page-debugging.patch
-VM_RESERVED-check.patch
-numa-memory-reporting-fix-2.patch
-ramfs-use-generic_file_llseek.patch
-inode_change_ok-remove-lock_kernel.patch
-nommu-vmtruncate-no_lock_kernel.patch
-proc-lock_kernel-removal.patch
-fops-flush-no-lock_kernel.patch
-block_llseek-no-lock_kernel.patch
-TC35815-config-fix.patch
-CLONE_DETACHED-exit-fix.patch
-security_vm_enough_memory.patch
-rename-timer-A1.patch
-lost-tick-speedstep-fix-A1.patch
-lost-tick-corner-fix-A0.patch
-lowmem_page_address-cleanup.patch
-ext2_new_inode-race-fix.patch
-double-mmdrop-fix.patch
-cciss-hang-fix.patch
-journal_release_buffer-race-fix.patch
Merged
-HZ-100.patch
Go back to 1000 Hz
+misc8.patch
Misc fixes
-irqreturn-snd-via-fix.patch
-config-PAGE_OFFSET.patch
-lru_cache_add-check.patch
-skip-apic-ids-on-boot.patch
-bio-debug-trap.patch
-sound-irq-hack.patch
Dropped.
+linux-isp-2-fix-again.patch
Fix non-modular feral driver
+xattr-cleanup.patch
+xattr-sharing.patch
+xattr-just-replace.patch
+xattr-fine-grained-locking-prep.patch
+xattr-fine-grained-locking.patch
Finer-grained locking in the ext2 and ext3 extended attribute code.
-as-double-free-and-debug.patch
-as-fix-seek-estimation.patch
-as-fix-seeky-loads.patch
Folded into as-iosched.patch
-blk-fair-batches-2.patch
Folded into blk-fair-batches.patch
+nbd-docco-update.patch
NBD documentation
+cpumask_t-1.patch
Support up to 255 CPUs
-div64-cleanup.patch
Waiting for an update
+apci-nmi-watchdog-fix.patch
ACPI triggers the NMI watchdog during poweroff. Fix.
+fnup-stats.patch
Some debug stuff which wasn't supposed to be here.
+bootmem-fixes.patch
Minor bootmem fixes
+jiffies-include-fixes.patch
Build fix
+epoll-optimisations.patch
eventpoll warmups
+o1-interactivity.patch
Con's scheduler tweaks
+fix-user-leak.patch
Fix a possible memory leak
+mtd-build-fix.patch
Build fix
All 116 patches:
linus.patch
mm.patch
add -mmN to EXTRAVERSION
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdb-use-ggdb.patch
kgdb-ga-docco-fixes.patch
kgdb doc. edits/corrections
misc8.patch
misc fixes
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-pci-update.patch
ppc64-reloc_hide.patch
ppc64-semaphore-reimplementation.patch
ppc64: use the ia32 semaphore implementation
sym-do-160.patch
make the SYM driver do 160 MB/sec
x86_64-fixes.patch
x86_64 fixes
delay-ksoftirqd-fallback.patch
Try harded in IRQ context before falling back to ksoftirqd
fb-image-depth-fix.patch
fbdev image depth fix
ds-09-vicam-usercopy-fix.patch
vicam usercopy fix
buffer-debug.patch
buffer.c debugging
ipcsem-speedup.patch
ipc semaphore optimization
rcu-stats.patch
RCU statistics reporting
mtrr-hang-fix.patch
Fix mtrr-related hang
reslabify-pgds-and-pmds.patch
re-slabify i386 pgd's and pmd's
intel8x0-cleanup.patch
intel8x0 cleanups
bio-too-big-fix.patch
Fix raid "bio too big" failures
linux-isp-2.patch
linux-isp-2-fix-again.patch
lost feral fix
list_del-debug.patch
list_del debug check
airo-schedule-fix.patch
airo.c: don't sleep in atomic regions
xattr-cleanup.patch
xattr: cleanups
xattr-sharing.patch
xattr: blockdev inode selection fix
xattr-just-replace.patch
xattr: update-in-place optimisation
xattr-fine-grained-locking-prep.patch
xattrr: preparation for fine-grained locking
xattr-fine-grained-locking.patch
xattr: fine-grained locking
resurrect-batch_requests.patch
bring back the batch_requests function
kblockd.patch
Create `kblockd' workqueue
cfq-infrastructure.patch
elevator-completion-api.patch
elevator completion API
as-iosched.patch
anticipatory I/O scheduler
AS: pgbench improvement
AS: discrete read fifo batches
AS sync/async batches
AS: hash removal fix
AS jumbo patch (for SCSI and TCQ)
AS: fix stupid thinko
AS: no batch-antic-limit
AS: autotune write batches
AS: divide by zero fix
AS: more HZ != 1000 fixes
AS: update_write_batch tuning
AS locking
AS HZ fixes
AS: fix a leak + more debugging
AS: maybe repair performance drop of random read O_DIRECT
AS: fix IBM's seek load
unplug-use-kblockd.patch
Use kblockd for running request queues
per-queue-nr_requests.patch
per queue nr_requests
blk-invert-watermarks.patch
blk_congestion_wait threshold cleanup
blk-as-hint.patch
blk-as-hint
get_request_wait-oom-fix.patch
handle OOM in get_request_wait().
blk-fair-batches.patch
blk-fair-batches
blk fair batches #2
generic-io-contexts.patch
generic io contexts
blk-request-batching.patch
block request batching
get_io_context-fix.patch
get_io_context fixes
blk-allocation-commentary.patch
block allocation comments
blk-batching-throttle-fix.patch
blk batch requests fix
blk-batching-cleanups.patch
block batching cleanups
print-build-options-on-oops.patch
print a few config options on oops
mmap-prefault.patch
prefault of executable mmaps
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
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
invalidate_mmap_range.patch
Interface to invalidate regions of mmaps
aio-mm-refcounting-fix.patch
fix /proc mm_struct refcounting bug
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 <suparna@in.ibm.com>
Subject: Re: 2.5.72-mm1 - Under heavy testing with AIO,.. vmstat seems to blow the kernel
vfsmount_lock.patch
From: Maneesh Soni <maneesh@in.ibm.com>
Subject: [patch 1/2] vfsmount_lock
sched-hot-balancing-fix.patch
fix for CPU scheduler load distribution
truncate-pagefault-race-fix.patch
Fix vmtruncate race and distributed filesystem race
truncate-pagefault-race-fix-fix.patch
Make sure truncate fix has no race
sleepometer.patch
sleep instrumentation
time-goes-backwards.patch
demonstrate do_gettimeofday() going backwards
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
seqcount-locking.patch
i_size atomic access: infrastructure
i_size-atomic-access.patch
i_size atomic access
aha152x-oops-fix.patch
aha152X oops fixes
nbd-cleanups.patch
NBD: cosmetic cleanups
nbd-enhanced-diagnostics.patch
nbd: enhanced diagnostics support
nbd-remove-blksize-bits.patch
nbd: remove unneeded blksize_bits field
nbd-kobject-oops-fix.patch
nbd: initialise the embedded kobject
nbd-paranioa-cleanups.patch
nbd: cleanup PARANOIA usage & code
nbd-locking-fixes.patch
nbd: fix locking issues with ioctl UI
nbd-ioctl-compat.patch
nbd: add compatibility with previous ioctl user interface
nbd-docco-update.patch
NBD documentation update
cpumask_t-1.patch
acpismp-fix.patch
ACPI_HT_ONLY acpismp=force
oomkill-if-free-swap.patch
Don't skip oomkilling if there's free swap
exec_mmap-is-the-point-of-no-return.patch
after exec_mmap(), exec cannot fail
apci-nmi-watchdog-fix.patch
ACPI poweroff trigers the NMI watchdog
fnup-stats.patch
bootmem-fixes.patch
bootmem.c cleanups
jiffies-include-fixes.patch
jiffies include fixes
epoll-optimisations.patch
epoll: microoptimisations
o1-interactivity.patch
CPU scheduler interactivity patch
fix-user-leak.patch
fix current->user->__count leak for processes
mtd-build-fix.patch
MTD build fix for old gcc's
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
@ 2003-07-03 10:45 ` Dumitru Ciobarcianu
2003-07-03 11:07 ` William Lee Irwin III
2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
` (7 subsequent siblings)
8 siblings, 1 reply; 90+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 10:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Here are the errors:
CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
make[1]: *** [arch/i386/kernel/cpu] Error 2
make: *** [arch/i386/kernel] Error 2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
@ 2003-07-03 11:07 ` William Lee Irwin III
2003-07-03 11:17 ` Dumitru Ciobarcianu
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-03 11:07 UTC (permalink / raw)
To: Dumitru Ciobarcianu; +Cc: Andrew Morton, linux-kernel, linux-mm
On Thu, Jul 03, 2003 at 01:45:41PM +0300, Dumitru Ciobarcianu wrote:
> Here are the errors:
> CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
> make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
> make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
> make[1]: *** [arch/i386/kernel/cpu] Error 2
> make: *** [arch/i386/kernel] Error 2
Would something like this help?
-- wli
===== arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 1.16 vs edited =====
--- 1.16/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Mon May 12 21:23:13 2003
+++ edited/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Thu Jul 3 04:07:01 2003
@@ -53,10 +53,9 @@
static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
{
u32 l, h;
- unsigned long cpus_allowed;
+ cpumask_t cpus_allowed, affected_cpu_map;
struct cpufreq_freqs freqs;
int hyperthreading = 0;
- int affected_cpu_map = 0;
int sibling = 0;
if (!cpu_online(cpu) || (newstate > DC_DISABLE) ||
@@ -67,16 +66,17 @@
cpus_allowed = current->cpus_allowed;
/* only run on CPU to be set, or on its sibling */
- affected_cpu_map = 1 << cpu;
+ affected_cpu_map = cpumask_of_cpu(cpu);
#ifdef CONFIG_X86_HT
hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
if (hyperthreading) {
sibling = cpu_sibling_map[cpu];
- affected_cpu_map |= (1 << sibling);
+ cpu_set(sibling, affected_cpu_map);
}
#endif
set_cpus_allowed(current, affected_cpu_map);
BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
+ BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
/* get current state */
rdmsr(MSR_IA32_THERM_CONTROL, l, h);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-03 11:07 ` William Lee Irwin III
@ 2003-07-03 11:17 ` Dumitru Ciobarcianu
2003-07-03 11:20 ` William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 11:17 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
I had to mannually change the file (the patch was giving rejects), but
it compiles now.
Thanks
//Cioby
On Thu, 2003-07-03 at 14:07, William Lee Irwin III wrote:
> On Thu, Jul 03, 2003 at 01:45:41PM +0300, Dumitru Ciobarcianu wrote:
> > Here are the errors:
> > CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
> > make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
> > make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
> > make[1]: *** [arch/i386/kernel/cpu] Error 2
> > make: *** [arch/i386/kernel] Error 2
>
> Would something like this help?
>
> -- wli
>
> ===== arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 1.16 vs edited =====
> --- 1.16/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Mon May 12 21:23:13 2003
> +++ edited/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Thu Jul 3 04:07:01 2003
> @@ -53,10 +53,9 @@
> static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
> {
> u32 l, h;
> - unsigned long cpus_allowed;
> + cpumask_t cpus_allowed, affected_cpu_map;
> struct cpufreq_freqs freqs;
> int hyperthreading = 0;
> - int affected_cpu_map = 0;
> int sibling = 0;
>
> if (!cpu_online(cpu) || (newstate > DC_DISABLE) ||
> @@ -67,16 +66,17 @@
> cpus_allowed = current->cpus_allowed;
>
> /* only run on CPU to be set, or on its sibling */
> - affected_cpu_map = 1 << cpu;
> + affected_cpu_map = cpumask_of_cpu(cpu);
> #ifdef CONFIG_X86_HT
> hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
> if (hyperthreading) {
> sibling = cpu_sibling_map[cpu];
> - affected_cpu_map |= (1 << sibling);
> + cpu_set(sibling, affected_cpu_map);
> }
> #endif
> set_cpus_allowed(current, affected_cpu_map);
> BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
> + BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
>
> /* get current state */
> rdmsr(MSR_IA32_THERM_CONTROL, l, h);
--
Cioby
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-03 11:17 ` Dumitru Ciobarcianu
@ 2003-07-03 11:20 ` William Lee Irwin III
2003-07-03 11:32 ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
2003-07-07 5:24 ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
0 siblings, 2 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-03 11:20 UTC (permalink / raw)
To: Dumitru Ciobarcianu; +Cc: Andrew Morton, linux-kernel, linux-mm
On Thu, Jul 03, 2003 at 02:17:48PM +0300, Dumitru Ciobarcianu wrote:
> I had to mannually change the file (the patch was giving rejects), but
> it compiles now.
Great! Could you send back the diff? (or alternatively, the file
contents if you didn't preserve the old contents) so I can send the
proper diff upstream?
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile) PATCH
2003-07-03 11:20 ` William Lee Irwin III
@ 2003-07-03 11:32 ` Dumitru Ciobarcianu
2003-07-07 5:24 ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
1 sibling, 0 replies; 90+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 11:32 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Thu, 2003-07-03 at 14:20, William Lee Irwin III wrote:
> Great! Could you send back the diff? (or alternatively, the file
> contents if you didn't preserve the old contents) so I can send the
> proper diff upstream?
I have attached the patch since evolution seems to really want to break
the patch if I do an "Insert text file" :(
--
Cioby
[-- Attachment #2: p4-clockmod.patch --]
[-- Type: text/plain, Size: 1237 bytes --]
--- /usr/src/linux-2.5.74/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c.original 2003-07-03 14:12:35.000000000 +0300
+++ /usr/src/linux-2.5.74/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2003-07-03 14:28:10.000000000 +0300
@@ -53,10 +53,9 @@
static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
{
u32 l, h;
- unsigned long cpus_allowed;
+ cpumask_t cpus_allowed, affected_cpu_map;
struct cpufreq_freqs freqs;
int hyperthreading = 0;
- int affected_cpu_map = 0;
int sibling = 0;
if (!cpu_online(cpu) || (newstate > DC_DISABLE) ||
@@ -67,16 +66,16 @@
cpus_allowed = current->cpus_allowed;
/* only run on CPU to be set, or on its sibling */
- affected_cpu_map = 1 << cpu;
+ affected_cpu_map = cpumask_of_cpu(cpu);
#ifdef CONFIG_X86_HT
hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
if (hyperthreading) {
sibling = cpu_sibling_map[cpu];
- affected_cpu_map |= (1 << sibling);
+ cpu_set(sibling, affected_cpu_map);
}
#endif
set_cpus_allowed(current, affected_cpu_map);
- BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
+ BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
/* get current state */
rdmsr(MSR_IA32_THERM_CONTROL, l, h);
^ permalink raw reply [flat|nested] 90+ messages in thread
* o1-interactivity.patch (was Re: 2.5.74-mm1)
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
@ 2003-07-03 13:15 ` Sean Neakums
2003-07-03 13:30 ` Con Kolivas
2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
` (6 subsequent siblings)
8 siblings, 1 reply; 90+ messages in thread
From: Sean Neakums @ 2003-07-03 13:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton <akpm@osdl.org> writes:
> . Included Con's CPU scheduler changes. Feedback on the effectiveness of
> this and the usual benchmarks would be interesting.
I find that this patch makes X really choppy when Mozilla Firebird is
loading a page (which it does through an ssh tunnel here). Both the X
pointer and the spinner in the tab that is loading stop and start, for
up to a second at a time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: o1-interactivity.patch (was Re: 2.5.74-mm1)
2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
@ 2003-07-03 13:30 ` Con Kolivas
0 siblings, 0 replies; 90+ messages in thread
From: Con Kolivas @ 2003-07-03 13:30 UTC (permalink / raw)
To: Sean Neakums, Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, 3 Jul 2003 23:15, Sean Neakums wrote:
> Andrew Morton <akpm@osdl.org> writes:
> > . Included Con's CPU scheduler changes. Feedback on the effectiveness of
> > this and the usual benchmarks would be interesting.
>
> I find that this patch makes X really choppy when Mozilla Firebird is
> loading a page (which it does through an ssh tunnel here). Both the X
> pointer and the spinner in the tab that is loading stop and start, for
> up to a second at a time.
Thanks for the feedback. I know about and am working on this one. No mention
of the rest of the performance?
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
@ 2003-07-03 16:02 ` Felipe Alfaro Solana
2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
` (5 subsequent siblings)
8 siblings, 0 replies; 90+ messages in thread
From: Felipe Alfaro Solana @ 2003-07-03 16:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, linux-mm
On Thu, 2003-07-03 at 11:37, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
>
> . Included Con's CPU scheduler changes. Feedback on the effectiveness of
> this and the usual benchmarks would be interesting.
>
> Changes to the CPU scheduler tend to cause surprising and subtle problems
> in areas where you least expect it, and these do take a long time to
> materialise. Alterations in there need to be made carefully and cautiously.
> We shall see...
Currently testing all the new things...
>From what I've seen until date, the new scheduler patches are very, very
promising. I like them very much, but I still prefer Mike+Ingo combo
patch a little bit more for my laptop.
Will keep you informed if I see something strange ;-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (2 preceding siblings ...)
2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
@ 2003-07-03 18:11 ` Pasi Savolainen
2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
` (4 subsequent siblings)
8 siblings, 0 replies; 90+ messages in thread
From: Pasi Savolainen @ 2003-07-03 18:11 UTC (permalink / raw)
To: linux-mm; +Cc: linux-kernel
* Andrew Morton <akpm@osdl.org>:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
>
Has -mm had some monotonic clock patches at around 2.5.72-mm3?
2.5.74-mm1 seems to produce non-monotonic gettimeofday.
(tested with http://www.swcp.com/~hudson/gettimeofday.c)
'lag' is sporadic and may take several iterations to come up.
Machine is 2xK7 with a ACPI C2 sleep driver (TSC's get unsynched).
2.5.72-mm3 didn't show these.
--
Psi -- <http://www.iki.fi/pasi.savolainen>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (3 preceding siblings ...)
2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
@ 2003-07-03 20:25 ` William Lee Irwin III
2003-07-03 20:48 ` 2.5.74-mm1 William Lee Irwin III
2003-07-04 8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
` (3 subsequent siblings)
8 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-03 20:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> . Mainly a resync with various things and people. Plus a few fixlets.
> . I dropped out a few patches which weren't really proving useful.
> . Included Con's CPU scheduler changes. Feedback on the effectiveness of
> this and the usual benchmarks would be interesting.
> Changes to the CPU scheduler tend to cause surprising and subtle problems
> in areas where you least expect it, and these do take a long time to
> materialise. Alterations in there need to be made carefully and cautiously.
> We shall see...
Here's a resync of highpmd, the big PAE resource scalability patch that
saves 12KB per process of lowmem. It adds pmd accessors analogous to
pte_offset_map() etc., i.e. pmd_offset_map(), pmd_unmap(), etc.
-- wli
[-- Attachment #2: highpmd-2.5.74-mm2-1.bz2 --]
[-- Type: application/octet-stream, Size: 14196 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-03 20:48 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-03 20:48 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 347 bytes --]
On Thu, Jul 03, 2003 at 01:25:37PM -0700, William Lee Irwin III wrote:
> Here's a resync of highpmd, the big PAE resource scalability patch that
> saves 12KB per process of lowmem. It adds pmd accessors analogous to
> pte_offset_map() etc., i.e. pmd_offset_map(), pmd_unmap(), etc.
And here's a resync of the right version of the thing:
-- wli
[-- Attachment #2: highpmd-2.5.74-mm1-1.bz2 --]
[-- Type: application/octet-stream, Size: 15616 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
@ 2003-07-04 8:53 ` William Lee Irwin III
2003-07-04 9:35 ` William Lee Irwin III
1 sibling, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 8:53 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 10:55:37AM +0200, Helge Hafting wrote:
> 2.5.74-mm1 dies very early during bootup due to some APIC trouble:
> (written down by hand)
> Posix conformance testing by UNIFIX
> enabled Extint on cpu #0
> ESR before enabling vector 00000000
> ESR after enabling vector 00000000
> Enabling IP-APIC IRQs
> BIOS bug, IO-APIC #0 ID2 is already used!...
> kernel panic: Max APIC ID exceeded!
Okay, fixing.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (4 preceding siblings ...)
2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-04 8:55 ` Helge Hafting
2003-07-04 8:53 ` William Lee Irwin III
2003-07-04 9:35 ` William Lee Irwin III
2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
` (2 subsequent siblings)
8 siblings, 2 replies; 90+ messages in thread
From: Helge Hafting @ 2003-07-04 8:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
2.5.74-mm1 dies very early during bootup due to some APIC trouble:
(written down by hand)
Posix conformance testing by UNIFIX
enabled Extint on cpu #0
ESR before enabling vector 00000000
ESR after enabling vector 00000000
Enabling IP-APIC IRQs
BIOS bug, IO-APIC #0 ID2 is already used!...
kernel panic: Max APIC ID exceeded!
Here is the corresponding log for 2.5.73mm3
(pasted from dmesg)
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-11, 2-17, 2-19 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 22.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00178014
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0014
.... register #02: 02000000
....... : arbitration: 02
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 001 01 0 0 0 0 0 1 1 51
07 001 01 0 0 0 0 0 1 1 59
08 001 01 0 0 0 0 0 1 1 61
09 000 00 1 0 0 0 0 0 0 00
0a 001 01 0 0 0 0 0 1 1 69
0b 000 00 1 0 0 0 0 0 0 00
0c 001 01 0 0 0 0 0 1 1 71
0d 001 01 0 0 0 0 0 1 1 79
0e 001 01 0 0 0 0 0 1 1 81
0f 001 01 0 0 0 0 0 1 1 89
10 001 01 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 001 01 1 1 0 1 0 1 1 99
13 000 00 1 0 0 0 0 0 0 00
14 001 01 1 1 0 1 0 1 1 A1
15 001 01 1 1 0 1 0 1 1 A9
16 001 01 1 1 0 1 0 1 1 B1
17 001 01 1 1 0 1 0 1 1 B9
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ10 -> 0:10
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2390.3168 MHz.
..... host bus clock speed is 132.7952 MHz.
mtrr: v2.0 (20020519)
Seems the kernel wants to use APIC ID2, but
2.5.74 claims the BIOS used it up?
Some more APIC related info from 2.5.73mm3 dmesg:
511MB LOWMEM available.
found SMP MP-table at 000f5670
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 15:2 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
lspci output, in case it matters:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host &
Memory & AGP Controller
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 04)
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
SiS7012 PCI Audio Accelerator (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB
Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB
Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB
Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0
00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
This is a desktop P4 with 512M. The kernel is a UP kernel.
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
2003-07-04 8:53 ` William Lee Irwin III
@ 2003-07-04 9:35 ` William Lee Irwin III
2003-07-04 9:50 ` William Lee Irwin III
1 sibling, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 9:35 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 10:55:37AM +0200, Helge Hafting wrote:
> 2.5.74-mm1 dies very early during bootup due to some APIC trouble:
> (written down by hand)
> Posix conformance testing by UNIFIX
> enabled Extint on cpu #0
> ESR before enabling vector 00000000
> ESR after enabling vector 00000000
> Enabling IP-APIC IRQs
> BIOS bug, IO-APIC #0 ID2 is already used!...
> kernel panic: Max APIC ID exceeded!
Okay, now for the "final solution" wrt. sparse physical APIC ID's
in addition to what I hope is a fix for your bug. This uses a separate
bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
APIC ID bitmaps.
\begin{cross-fingers}
-- wli
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/apic.c virgin_cpu-2.5.74-2/arch/i386/kernel/apic.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/apic.c 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/apic.c 2003-07-04 02:29:01.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
connect_bsp_APIC();
- phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+ phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
setup_local_APIC();
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/io_apic.c virgin_cpu-2.5.74-2/arch/i386/kernel/io_apic.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/io_apic.c 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/io_apic.c 2003-07-04 02:29:01.000000000 -0700
@@ -1600,7 +1600,7 @@ void disable_IO_APIC(void)
static void __init setup_ioapic_ids_from_mpc(void)
{
union IO_APIC_reg_00 reg_00;
- cpumask_t phys_id_present_map;
+ physid_mask_t phys_id_present_map;
int apic;
int i;
unsigned char old_id;
@@ -1614,8 +1614,7 @@ static void __init setup_ioapic_ids_from
* This is broken; anything with a real cpu count has to
* circumvent this idiocy regardless.
*/
- phys_id_present_map =
- ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
/*
* Set the IOAPIC ID to the value stored in the MPC table.
@@ -1646,20 +1645,20 @@ static void __init setup_ioapic_ids_from
mp_ioapics[apic].mpc_apicid)) {
printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
apic, mp_ioapics[apic].mpc_apicid);
- for (i = 0; i < 0xf; i++)
- if (!cpu_isset(i, phys_id_present_map))
+ for (i = 0; i < APIC_BROADCAST_ID; i++)
+ if (!physid_isset(i, phys_id_present_map))
break;
- if (i >= 0xf)
+ if (i >= APIC_BROADCAST_ID)
panic("Max APIC ID exceeded!\n");
printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
i);
- cpu_set(i, phys_id_present_map);
+ physid_set(i, phys_id_present_map);
mp_ioapics[apic].mpc_apicid = i;
} else {
- cpumask_t tmp;
+ physid_mask_t tmp;
tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
- cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+ physids_or(phys_id_present_map, phys_id_present_map, tmp);
}
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
int __init io_apic_get_unique_id (int ioapic, int apic_id)
{
union IO_APIC_reg_00 reg_00;
- static cpumask_t apic_id_map = CPU_MASK_NONE;
- cpumask_t tmp;
+ static physid_mask_t apic_id_map = CPU_MASK_NONE;
+ physid_mask_t tmp;
unsigned long flags;
int i = 0;
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
* advantage of new APIC bus architecture.
*/
- if (cpus_empty(apic_id_map))
- apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ if (physids_empty(apic_id_map))
+ apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
spin_lock_irqsave(&ioapic_lock, flags);
reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
}
tmp = apicid_to_cpu_present(apic_id);
- cpus_or(apic_id_map, apic_id_map, tmp);
+ physids_or(apic_id_map, apic_id_map, tmp);
if (reg_00.bits.ID != apic_id) {
reg_00.bits.ID = apic_id;
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/mpparse.c virgin_cpu-2.5.74-2/arch/i386/kernel/mpparse.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/mpparse.c 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/mpparse.c 2003-07-04 02:29:01.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
static unsigned int __initdata num_processors;
/* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
void __init MP_processor_info (struct mpc_config_processor *m)
{
int ver, apicid;
- cpumask_t tmp;
+ physid_mask_t tmp;
if (!(m->mpc_cpuflag & CPU_ENABLED))
return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
ver = m->mpc_apicver;
tmp = apicid_to_cpu_present(apicid);
- cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+ physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
/*
* Validate version
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/smpboot.c virgin_cpu-2.5.74-2/arch/i386/kernel/smpboot.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/smpboot.c 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/smpboot.c 2003-07-04 02:31:37.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
if (!smp_found_config) {
printk(KERN_NOTICE "SMP motherboard not detected.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
if (APIC_init_uniprocessor())
printk(KERN_NOTICE "Local APIC not detected."
" Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
boot_cpu_physical_apicid);
printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
smp_found_config = 0;
printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
kicked = 1;
- for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+ for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
apicid = cpu_present_to_apicid(bit);
/*
* Don't even attempt to start the boot CPU!
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/genapic.h virgin_cpu-2.5.74-2/include/asm-i386/genapic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/genapic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/genapic.h 2003-07-04 02:29:01.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic {
int int_dest_mode;
int apic_broadcast_id;
int esr_disable;
- unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid);
+ unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid);
unsigned long (*check_apicid_present)(int apicid);
int no_balance_irq;
void (*init_apic_ldr)(void);
- cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map);
+ physid_mask_t (*ioapic_phys_id_map)(cpumask_const_t map);
void (*clustered_apic_check)(void);
int (*multi_timer_check)(int apic, int irq);
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
int (*cpu_present_to_apicid)(int mps_cpu);
- cpumask_t (*apicid_to_cpu_present)(int phys_apicid);
+ physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
int (*mpc_apic_id)(struct mpc_config_processor *m,
struct mpc_config_translation *t);
void (*setup_portio_remap)(void);
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-bigsmp/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
return m->mpc_apicid;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
#define WAKE_SECONDARY_VIA_INIT
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-default/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-default/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-default/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-default/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
#define APIC_BROADCAST_ID 0x0F
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
- return cpu_isset_const(apicid, bitmap);
+ return physid_isset(apicid, bitmap);
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
/*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
apic_write_around(APIC_LDR, val);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
- cpumask_t ret;
- cpus_copy_const(ret, phys_map);
- return ret;
+ return phys_map;
}
static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-es7000/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-es7000/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
#define APIC_BROADCAST_ID (0xff)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- static int cpu = 0;
- cpumask_t mask;
- mask = cpumask_of_cpu(cpu);
- ++cpu;
+ static int id = 0;
+ physid_mask_t mask;
+ mask = physid_mask_of_physid(id);
+ ++id;
return mask;
}
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
return (m->mpc_apicid);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xff);
+ return physids_promote(0xff);
}
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-numaq/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-numaq/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
#define INT_DEST_MODE 0 /* physical delivery on LOCAL quad */
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
#define apicid_cluster(apicid) (apicid & 0xF0)
static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int
return apic != 0 && irq == 0;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* We don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
/* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
return logical_apicid >> 4;
}
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
{
int node = apicid_to_node(logical_apicid);
int cpu = __ffs(logical_apicid & 0xf);
- return cpumask_of_cpu(cpu + 4*node);
+ return physid_mask_of_physid(cpu + 4*node);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-summit/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-summit/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE (dest_Fixed)
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0x0F);
+ return physids_promote(0x0F);
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(0);
+ return physid_mask_of_physid(0);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-visws/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-visws/mach_apic.h 2003-07-04 02:29:01.000000000 -0700
@@ -16,12 +16,12 @@
#endif
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
/*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(apicid);
+ return physid_mask_of_physid(apicid);
}
#define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mpspec.h virgin_cpu-2.5.74-2/include/asm-i386/mpspec.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mpspec.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mpspec.h 2003-07-04 02:29:01.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
extern int smp_found_config;
extern void find_smp_config (void);
extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
extern void mp_parse_prt (void);
#endif /*CONFIG_ACPI_BOOT*/
+#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+ unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map) set_bit(physid, (map).mask)
+#define physid_clear(physid, map) clear_bit(physid, (map).mask)
+#define physid_isset(physid, map) test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map) test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2) bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2) bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map) bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map) bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map) bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2) bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map) bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n) bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n) bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map) ((map).mask[0])
+
+#define physids_promote(physids) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ __physid_mask.mask[0] = physids; \
+ __physid_mask; \
+ })
+
+#define physid_mask_of_physid(physid) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ physid_set(physid, __physid_mask); \
+ __physid_mask; \
+ })
+
+#define PHYSID_MASK_ALL { {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE { {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
#endif
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/smp.h virgin_cpu-2.5.74-2/include/asm-i386/smp.h
--- virgin_cpu-2.5.74-1/include/asm-i386/smp.h 2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/smp.h 2003-07-04 02:29:01.000000000 -0700
@@ -32,7 +32,7 @@
*/
extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
extern int pic_mode;
extern int smp_num_siblings;
extern int cpu_sibling_map[];
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 9:35 ` William Lee Irwin III
@ 2003-07-04 9:50 ` William Lee Irwin III
2003-07-04 10:02 ` William Lee Irwin III
2003-07-04 15:41 ` Martin J. Bligh
0 siblings, 2 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 9:50 UTC (permalink / raw)
To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
> Okay, now for the "final solution" wrt. sparse physical APIC ID's
> in addition to what I hope is a fix for your bug. This uses a separate
> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
> APIC ID bitmaps.
> \begin{cross-fingers}
This time diffed against the right tree:
diff -prauN mm1-2.5.74-1/arch/i386/kernel/apic.c physid-2.5.74-1/arch/i386/kernel/apic.c
--- mm1-2.5.74-1/arch/i386/kernel/apic.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/apic.c 2003-07-04 02:45:17.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
connect_bsp_APIC();
- phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+ phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
setup_local_APIC();
diff -prauN mm1-2.5.74-1/arch/i386/kernel/io_apic.c physid-2.5.74-1/arch/i386/kernel/io_apic.c
--- mm1-2.5.74-1/arch/i386/kernel/io_apic.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/io_apic.c 2003-07-04 02:45:17.000000000 -0700
@@ -1601,7 +1601,7 @@ void disable_IO_APIC(void)
static void __init setup_ioapic_ids_from_mpc(void)
{
union IO_APIC_reg_00 reg_00;
- cpumask_t phys_id_present_map;
+ physid_mask_t phys_id_present_map;
int apic;
int i;
unsigned char old_id;
@@ -1615,8 +1615,7 @@ static void __init setup_ioapic_ids_from
* This is broken; anything with a real cpu count has to
* circumvent this idiocy regardless.
*/
- phys_id_present_map =
- ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
/*
* Set the IOAPIC ID to the value stored in the MPC table.
@@ -1647,20 +1646,20 @@ static void __init setup_ioapic_ids_from
mp_ioapics[apic].mpc_apicid)) {
printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
apic, mp_ioapics[apic].mpc_apicid);
- for (i = 0; i < 0xf; i++)
- if (!cpu_isset(i, phys_id_present_map))
+ for (i = 0; i < APIC_BROADCAST_ID; i++)
+ if (!physid_isset(i, phys_id_present_map))
break;
- if (i >= 0xf)
+ if (i >= APIC_BROADCAST_ID)
panic("Max APIC ID exceeded!\n");
printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
i);
- cpu_set(i, phys_id_present_map);
+ physid_set(i, phys_id_present_map);
mp_ioapics[apic].mpc_apicid = i;
} else {
- cpumask_t tmp;
+ physid_mask_t tmp;
tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
- cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+ physids_or(phys_id_present_map, phys_id_present_map, tmp);
}
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
int __init io_apic_get_unique_id (int ioapic, int apic_id)
{
union IO_APIC_reg_00 reg_00;
- static cpumask_t apic_id_map = CPU_MASK_NONE;
- cpumask_t tmp;
+ static physid_mask_t apic_id_map = CPU_MASK_NONE;
+ physid_mask_t tmp;
unsigned long flags;
int i = 0;
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
* advantage of new APIC bus architecture.
*/
- if (cpus_empty(apic_id_map))
- apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ if (physids_empty(apic_id_map))
+ apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
spin_lock_irqsave(&ioapic_lock, flags);
reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
}
tmp = apicid_to_cpu_present(apic_id);
- cpus_or(apic_id_map, apic_id_map, tmp);
+ physids_or(apic_id_map, apic_id_map, tmp);
if (reg_00.bits.ID != apic_id) {
reg_00.bits.ID = apic_id;
diff -prauN mm1-2.5.74-1/arch/i386/kernel/mpparse.c physid-2.5.74-1/arch/i386/kernel/mpparse.c
--- mm1-2.5.74-1/arch/i386/kernel/mpparse.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/mpparse.c 2003-07-04 02:45:17.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
static unsigned int __initdata num_processors;
/* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
void __init MP_processor_info (struct mpc_config_processor *m)
{
int ver, apicid;
- cpumask_t tmp;
+ physid_mask_t tmp;
if (!(m->mpc_cpuflag & CPU_ENABLED))
return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
ver = m->mpc_apicver;
tmp = apicid_to_cpu_present(apicid);
- cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+ physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
/*
* Validate version
diff -prauN mm1-2.5.74-1/arch/i386/kernel/smpboot.c physid-2.5.74-1/arch/i386/kernel/smpboot.c
--- mm1-2.5.74-1/arch/i386/kernel/smpboot.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/smpboot.c 2003-07-04 02:45:17.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
if (!smp_found_config) {
printk(KERN_NOTICE "SMP motherboard not detected.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
if (APIC_init_uniprocessor())
printk(KERN_NOTICE "Local APIC not detected."
" Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
boot_cpu_physical_apicid);
printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
smp_found_config = 0;
printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
kicked = 1;
- for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+ for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
apicid = cpu_present_to_apicid(bit);
/*
* Don't even attempt to start the boot CPU!
diff -prauN mm1-2.5.74-1/include/asm-i386/genapic.h physid-2.5.74-1/include/asm-i386/genapic.h
--- mm1-2.5.74-1/include/asm-i386/genapic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/genapic.h 2003-07-04 02:48:52.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic {
int int_dest_mode;
int apic_broadcast_id;
int esr_disable;
- unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid);
+ unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid);
unsigned long (*check_apicid_present)(int apicid);
int no_balance_irq;
void (*init_apic_ldr)(void);
- cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map);
+ physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
void (*clustered_apic_check)(void);
int (*multi_timer_check)(int apic, int irq);
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
int (*cpu_present_to_apicid)(int mps_cpu);
- cpumask_t (*apicid_to_cpu_present)(int phys_apicid);
+ physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
int (*mpc_apic_id)(struct mpc_config_processor *m,
struct mpc_config_translation *t);
void (*setup_portio_remap)(void);
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:47:45.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
return m->mpc_apicid;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
#define WAKE_SECONDARY_VIA_INIT
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
#define APIC_BROADCAST_ID 0x0F
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
- return cpu_isset_const(apicid, bitmap);
+ return physid_isset(apicid, bitmap);
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
/*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
apic_write_around(APIC_LDR, val);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
- cpumask_t ret;
- cpus_copy_const(ret, phys_map);
- return ret;
+ return phys_map;
}
static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h 2003-07-04 02:46:36.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
#define APIC_BROADCAST_ID (0xff)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- static int cpu = 0;
- cpumask_t mask;
- mask = cpumask_of_cpu(cpu);
- ++cpu;
+ static int id = 0;
+ physid_mask_t mask;
+ mask = physid_mask_of_physid(id);
+ ++id;
return mask;
}
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
return (m->mpc_apicid);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xff);
+ return physids_promote(0xff);
}
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
#define INT_DEST_MODE 0 /* physical delivery on LOCAL quad */
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
#define apicid_cluster(apicid) (apicid & 0xF0)
static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int
return apic != 0 && irq == 0;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* We don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
/* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
return logical_apicid >> 4;
}
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
{
int node = apicid_to_node(logical_apicid);
int cpu = __ffs(logical_apicid & 0xf);
- return cpumask_of_cpu(cpu + 4*node);
+ return physid_mask_of_physid(cpu + 4*node);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h 2003-07-04 02:47:00.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE (dest_Fixed)
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0x0F);
+ return physids_promote(0x0F);
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(0);
+ return physid_mask_of_physid(0);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -16,12 +16,12 @@
#endif
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
/*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(apicid);
+ return physid_mask_of_physid(apicid);
}
#define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mpspec.h physid-2.5.74-1/include/asm-i386/mpspec.h
--- mm1-2.5.74-1/include/asm-i386/mpspec.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mpspec.h 2003-07-04 02:45:17.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
extern int smp_found_config;
extern void find_smp_config (void);
extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
extern void mp_parse_prt (void);
#endif /*CONFIG_ACPI_BOOT*/
+#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+ unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map) set_bit(physid, (map).mask)
+#define physid_clear(physid, map) clear_bit(physid, (map).mask)
+#define physid_isset(physid, map) test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map) test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2) bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2) bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map) bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map) bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map) bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2) bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map) bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n) bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n) bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map) ((map).mask[0])
+
+#define physids_promote(physids) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ __physid_mask.mask[0] = physids; \
+ __physid_mask; \
+ })
+
+#define physid_mask_of_physid(physid) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ physid_set(physid, __physid_mask); \
+ __physid_mask; \
+ })
+
+#define PHYSID_MASK_ALL { {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE { {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
#endif
diff -prauN mm1-2.5.74-1/include/asm-i386/smp.h physid-2.5.74-1/include/asm-i386/smp.h
--- mm1-2.5.74-1/include/asm-i386/smp.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/smp.h 2003-07-04 02:45:17.000000000 -0700
@@ -32,7 +32,7 @@
*/
extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
extern int pic_mode;
extern int smp_num_siblings;
extern int cpu_sibling_map[];
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 9:50 ` William Lee Irwin III
@ 2003-07-04 10:02 ` William Lee Irwin III
2003-07-04 10:07 ` William Lee Irwin III
2003-07-04 15:41 ` Martin J. Bligh
1 sibling, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 10:02 UTC (permalink / raw)
To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 02:50:04AM -0700, William Lee Irwin III wrote:
> This time diffed against the right tree:
And this time with a one-line typo fixed (it seemed to compile anyway):
s/CPU_MASK_NONE/PHYSID_MASK_NONE/ somewhere in io_apic.c where a physid
mask was being initialized.
diff -prauN mm1-2.5.74-1/arch/i386/kernel/apic.c physid-2.5.74-1/arch/i386/kernel/apic.c
--- mm1-2.5.74-1/arch/i386/kernel/apic.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/apic.c 2003-07-04 02:45:17.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
connect_bsp_APIC();
- phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+ phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
setup_local_APIC();
diff -prauN mm1-2.5.74-1/arch/i386/kernel/io_apic.c physid-2.5.74-1/arch/i386/kernel/io_apic.c
--- mm1-2.5.74-1/arch/i386/kernel/io_apic.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/io_apic.c 2003-07-04 02:53:32.000000000 -0700
@@ -1601,7 +1601,7 @@ void disable_IO_APIC(void)
static void __init setup_ioapic_ids_from_mpc(void)
{
union IO_APIC_reg_00 reg_00;
- cpumask_t phys_id_present_map;
+ physid_mask_t phys_id_present_map;
int apic;
int i;
unsigned char old_id;
@@ -1615,8 +1615,7 @@ static void __init setup_ioapic_ids_from
* This is broken; anything with a real cpu count has to
* circumvent this idiocy regardless.
*/
- phys_id_present_map =
- ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
/*
* Set the IOAPIC ID to the value stored in the MPC table.
@@ -1647,20 +1646,20 @@ static void __init setup_ioapic_ids_from
mp_ioapics[apic].mpc_apicid)) {
printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
apic, mp_ioapics[apic].mpc_apicid);
- for (i = 0; i < 0xf; i++)
- if (!cpu_isset(i, phys_id_present_map))
+ for (i = 0; i < APIC_BROADCAST_ID; i++)
+ if (!physid_isset(i, phys_id_present_map))
break;
- if (i >= 0xf)
+ if (i >= APIC_BROADCAST_ID)
panic("Max APIC ID exceeded!\n");
printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
i);
- cpu_set(i, phys_id_present_map);
+ physid_set(i, phys_id_present_map);
mp_ioapics[apic].mpc_apicid = i;
} else {
- cpumask_t tmp;
+ physid_mask_t tmp;
tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
- cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+ physids_or(phys_id_present_map, phys_id_present_map, tmp);
}
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
int __init io_apic_get_unique_id (int ioapic, int apic_id)
{
union IO_APIC_reg_00 reg_00;
- static cpumask_t apic_id_map = CPU_MASK_NONE;
- cpumask_t tmp;
+ static physid_mask_t apic_id_map = PHYSID_MASK_NONE;
+ physid_mask_t tmp;
unsigned long flags;
int i = 0;
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
* advantage of new APIC bus architecture.
*/
- if (cpus_empty(apic_id_map))
- apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+ if (physids_empty(apic_id_map))
+ apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
spin_lock_irqsave(&ioapic_lock, flags);
reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
}
tmp = apicid_to_cpu_present(apic_id);
- cpus_or(apic_id_map, apic_id_map, tmp);
+ physids_or(apic_id_map, apic_id_map, tmp);
if (reg_00.bits.ID != apic_id) {
reg_00.bits.ID = apic_id;
diff -prauN mm1-2.5.74-1/arch/i386/kernel/mpparse.c physid-2.5.74-1/arch/i386/kernel/mpparse.c
--- mm1-2.5.74-1/arch/i386/kernel/mpparse.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/mpparse.c 2003-07-04 02:45:17.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
static unsigned int __initdata num_processors;
/* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
void __init MP_processor_info (struct mpc_config_processor *m)
{
int ver, apicid;
- cpumask_t tmp;
+ physid_mask_t tmp;
if (!(m->mpc_cpuflag & CPU_ENABLED))
return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
ver = m->mpc_apicver;
tmp = apicid_to_cpu_present(apicid);
- cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+ physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
/*
* Validate version
diff -prauN mm1-2.5.74-1/arch/i386/kernel/smpboot.c physid-2.5.74-1/arch/i386/kernel/smpboot.c
--- mm1-2.5.74-1/arch/i386/kernel/smpboot.c 2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/smpboot.c 2003-07-04 02:45:17.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
if (!smp_found_config) {
printk(KERN_NOTICE "SMP motherboard not detected.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
if (APIC_init_uniprocessor())
printk(KERN_NOTICE "Local APIC not detected."
" Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
boot_cpu_physical_apicid);
printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
smp_found_config = 0;
printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
smpboot_clear_io_apic_irqs();
- phys_cpu_present_map = cpumask_of_cpu(0);
+ phys_cpu_present_map = physid_mask_of_physid(0);
return;
}
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
kicked = 1;
- for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+ for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
apicid = cpu_present_to_apicid(bit);
/*
* Don't even attempt to start the boot CPU!
diff -prauN mm1-2.5.74-1/include/asm-i386/genapic.h physid-2.5.74-1/include/asm-i386/genapic.h
--- mm1-2.5.74-1/include/asm-i386/genapic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/genapic.h 2003-07-04 02:48:52.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic {
int int_dest_mode;
int apic_broadcast_id;
int esr_disable;
- unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid);
+ unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid);
unsigned long (*check_apicid_present)(int apicid);
int no_balance_irq;
void (*init_apic_ldr)(void);
- cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map);
+ physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
void (*clustered_apic_check)(void);
int (*multi_timer_check)(int apic, int irq);
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
int (*cpu_present_to_apicid)(int mps_cpu);
- cpumask_t (*apicid_to_cpu_present)(int phys_apicid);
+ physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
int (*mpc_apic_id)(struct mpc_config_processor *m,
struct mpc_config_translation *t);
void (*setup_portio_remap)(void);
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:47:45.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
return m->mpc_apicid;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
#define WAKE_SECONDARY_VIA_INIT
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE dest_LowestPrio
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
#define APIC_BROADCAST_ID 0x0F
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
- return cpu_isset_const(apicid, bitmap);
+ return physid_isset(apicid, bitmap);
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
/*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
apic_write_around(APIC_LDR, val);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
- cpumask_t ret;
- cpus_copy_const(ret, phys_map);
- return ret;
+ return phys_map;
}
static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- return cpumask_of_cpu(phys_apicid);
+ return physid_mask_of_physid(phys_apicid);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h 2003-07-04 02:46:36.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
#define APIC_BROADCAST_ID (0xff)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
static inline unsigned long check_apicid_present(int bit)
{
- return cpu_isset(bit, phys_cpu_present_map);
+ return physid_isset(bit, phys_cpu_present_map);
}
#define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
{
- static int cpu = 0;
- cpumask_t mask;
- mask = cpumask_of_cpu(cpu);
- ++cpu;
+ static int id = 0;
+ physid_mask_t mask;
+ mask = physid_mask_of_physid(id);
+ ++id;
return mask;
}
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
return (m->mpc_apicid);
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0xff);
+ return physids_promote(0xff);
}
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
#define INT_DEST_MODE 0 /* physical delivery on LOCAL quad */
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
#define apicid_cluster(apicid) (apicid & 0xF0)
static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int
return apic != 0 && irq == 0;
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
{
/* We don't have a good way to do this yet - hack */
- return cpus_promote(0xFUL);
+ return physids_promote(0xFUL);
}
/* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
return logical_apicid >> 4;
}
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
{
int node = apicid_to_node(logical_apicid);
int cpu = __ffs(logical_apicid & 0xf);
- return cpumask_of_cpu(cpu + 4*node);
+ return physid_mask_of_physid(cpu + 4*node);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h 2003-07-04 02:47:00.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
#define INT_DELIVERY_MODE (dest_Fixed)
#define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
-#define APIC_BROADCAST_ID (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
{
return 0;
}
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
return (int) bios_cpu_apicid[mps_cpu];
}
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
{
/* For clustered we don't have a good way to do this yet - hack */
- return cpus_promote(0x0F);
+ return physids_promote(0x0F);
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(0);
+ return physid_mask_of_physid(0);
}
static inline int mpc_apic_id(struct mpc_config_processor *m,
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h 2003-07-04 02:45:17.000000000 -0700
@@ -16,12 +16,12 @@
#endif
#define APIC_BROADCAST_ID 0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
static inline int apic_id_registered(void)
{
- return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+ return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
}
/*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
return mps_cpu;
}
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
{
- return cpumask_of_cpu(apicid);
+ return physid_mask_of_physid(apicid);
}
#define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
{
- return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+ return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
}
static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mpspec.h physid-2.5.74-1/include/asm-i386/mpspec.h
--- mm1-2.5.74-1/include/asm-i386/mpspec.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mpspec.h 2003-07-04 02:45:17.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
extern int smp_found_config;
extern void find_smp_config (void);
extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
extern void mp_parse_prt (void);
#endif /*CONFIG_ACPI_BOOT*/
+#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+ unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map) set_bit(physid, (map).mask)
+#define physid_clear(physid, map) clear_bit(physid, (map).mask)
+#define physid_isset(physid, map) test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map) test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2) bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2) bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map) bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map) bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map) bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2) bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map) bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n) bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n) bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map) ((map).mask[0])
+
+#define physids_promote(physids) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ __physid_mask.mask[0] = physids; \
+ __physid_mask; \
+ })
+
+#define physid_mask_of_physid(physid) \
+ ({ \
+ physid_mask_t __physid_mask = PHYSID_MASK_NONE; \
+ physid_set(physid, __physid_mask); \
+ __physid_mask; \
+ })
+
+#define PHYSID_MASK_ALL { {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE { {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
#endif
diff -prauN mm1-2.5.74-1/include/asm-i386/smp.h physid-2.5.74-1/include/asm-i386/smp.h
--- mm1-2.5.74-1/include/asm-i386/smp.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/smp.h 2003-07-04 02:45:17.000000000 -0700
@@ -32,7 +32,7 @@
*/
extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
extern int pic_mode;
extern int smp_num_siblings;
extern int cpu_sibling_map[];
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 10:02 ` William Lee Irwin III
@ 2003-07-04 10:07 ` William Lee Irwin III
2003-07-04 11:12 ` Helge Hafting
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 10:07 UTC (permalink / raw)
To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 02:50:04AM -0700, William Lee Irwin III wrote:
>> This time diffed against the right tree:
On Fri, Jul 04, 2003 at 03:02:17AM -0700, William Lee Irwin III wrote:
> And this time with a one-line typo fixed (it seemed to compile anyway):
> s/CPU_MASK_NONE/PHYSID_MASK_NONE/ somewhere in io_apic.c where a physid
> mask was being initialized.
Unrelated tangent:
Nuke cpumask_arith.h; it's unused as of the requested updates to use
strong typing for all arches.
-- wli
diff -prauN physid-2.5.74-1/include/asm-generic/cpumask_arith.h physid-2.5.74-2/include/asm-generic/cpumask_arith.h
--- physid-2.5.74-1/include/asm-generic/cpumask_arith.h 2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-2/include/asm-generic/cpumask_arith.h 1969-12-31 16:00:00.000000000 -0800
@@ -1,61 +0,0 @@
-#ifndef __ASM_GENERIC_CPUMASK_ARITH_H
-#define __ASM_GENERIC_CPUMASK_ARITH_H
-
-#define cpu_set(cpu, map) \
- do { \
- map |= ((cpumask_t)1) << (cpu); \
- } while (0)
-#define cpu_clear(cpu, map) \
- do { \
- map &= ~(((cpumask_t)1) << (cpu)); \
- } while (0)
-#define cpu_isset(cpu, map) \
- ((map) & (((cpumask_t)1) << (cpu)))
-#define cpu_test_and_set(cpu, map) \
- test_and_set_bit(cpu, (unsigned long *)(&(map)))
-
-#define cpus_and(dst,src1,src2) do { dst = (src1) & (src2); } while (0)
-#define cpus_or(dst,src1,src2) do { dst = (src1) | (src2); } while (0)
-#define cpus_clear(map) do { map = 0; } while (0)
-#define cpus_complement(map) do { map = ~(map); } while (0)
-#define cpus_equal(map1, map2) ((map1) == (map2))
-#define cpus_empty(map) ((map) == 0)
-
-#if BITS_PER_LONG == 32
-#if NR_CPUS <= 32
-#define cpus_weight(map) hweight32(map)
-#else
-#define cpus_weight(map) \
-({ \
- u32 *__map = (u32 *)(&(map)); \
- hweight32(__map[0]) + hweight32(__map[1]); \
-})
-#endif
-#elif BITS_PER_LONG == 64
-#define cpus_weight(map) hweight64(map)
-#endif
-
-#define cpus_shift_right(dst, src, n) do { dst = (src) >> (n); } while (0)
-#define cpus_shift_left(dst, src, n) do { dst = (src) >> (n); } while (0)
-
-#define any_online_cpu(map) (!cpus_empty(map))
-
-
-#define CPU_MASK_ALL (~((cpumask_t)0) >> (8*sizeof(cpumask_t) - NR_CPUS))
-#define CPU_MASK_NONE ((cpumask_t)0)
-
-/* only ever use this for things that are _never_ used on large boxen */
-#define cpus_coerce(map) ((unsigned long)(map))
-#define cpus_promote(map) ({ map; })
-#define cpumask_of_cpu(cpu) ({ ((cpumask_t)1) << (cpu); })
-
-#ifdef CONFIG_SMP
-#define first_cpu(map) __ffs(map)
-#define next_cpu(cpu, map) \
- __ffs((map) & ~(((cpumask_t)1 << (cpu)) - 1))
-#else
-#define first_cpu(map) 0
-#define next_cpu(cpu, map) 1
-#endif /* CONFIG_SMP */
-
-#endif /* __ASM_GENERIC_CPUMASK_ARITH_H */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 11:12 ` Helge Hafting
@ 2003-07-04 11:10 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 11:10 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 01:12:12PM +0200, Helge Hafting wrote:
> I applied both of your recent patches, and the patched
> 2.5.74-mm1 kernel came up fine. :-)
Terrific!
Sorry about the confusion at first. I apparently made a boo boo when
sizing the physid maps as NR_CPUS bits.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 10:07 ` William Lee Irwin III
@ 2003-07-04 11:12 ` Helge Hafting
2003-07-04 11:10 ` William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Helge Hafting @ 2003-07-04 11:12 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
I applied both of your recent patches, and the patched
2.5.74-mm1 kernel came up fine. :-)
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-11, 2-17, 2-19 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 22.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 9:50 ` William Lee Irwin III
2003-07-04 10:02 ` William Lee Irwin III
@ 2003-07-04 15:41 ` Martin J. Bligh
2003-07-04 15:47 ` Zwane Mwaikambo
2003-07-04 18:26 ` William Lee Irwin III
1 sibling, 2 replies; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 15:41 UTC (permalink / raw)
To: William Lee Irwin III, Helge Hafting, Andrew Morton,
linux-kernel, linux-mm
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>> in addition to what I hope is a fix for your bug. This uses a separate
>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>> APIC ID bitmaps.
>> \begin{cross-fingers}
Is it really necessary to turn half the apic code upside down in order
to fix this? What's the actual bugfix that's buried in this cleanup?
Despite the fact you seem to have gone out of your way to make this
hard to review, there are a few things I can see that strike me as odd.
Not necessarily wrong, but requiring more explanation.
> - if (i >= 0xf)
> + if (i >= APIC_BROADCAST_ID)
Is that always correct? it's not equivalent.
> - for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
> + for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
Is that the actual one-line bugfix this is all about?
> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:47:45.000000000 -0700
> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
> #define INT_DELIVERY_MODE dest_LowestPrio
> #define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
>
> -#define APIC_BROADCAST_ID (0x0f)
> +#define APIC_BROADCAST_ID (0xff)
So ... you've tested that change on a bigsmp machine, right?
At least, provide some reasoning here. Like this comment further down the
patch ...
> +/*
> + * this isn't really broadcast, just a (potentially inaccurate) upper
> + * bound for valid physical APIC id's
> + */
Which makes the change just look wrong to me. If you're thinking
"physical clustered mode" that terminology just utterly confusing crap,
and the change is wrong, as far as I can see.
> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
> 2003-07-04 02:45:17.000000000 -0700
>
> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
> {
> int node = apicid_to_node(logical_apicid);
> int cpu = __ffs(logical_apicid & 0xf);
>
> - return cpumask_of_cpu(cpu + 4*node);
> + return physid_mask_of_physid(cpu + 4*node);
> }
Hmmmm. What are you using physical apicids here for? They seem
irrelevant to this function.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 15:41 ` Martin J. Bligh
@ 2003-07-04 15:47 ` Zwane Mwaikambo
2003-07-04 16:18 ` Martin J. Bligh
2003-07-04 18:29 ` William Lee Irwin III
2003-07-04 18:26 ` William Lee Irwin III
1 sibling, 2 replies; 90+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04 15:47 UTC (permalink / raw)
To: Martin J. Bligh
Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
linux-kernel, linux-mm
On Fri, 4 Jul 2003, Martin J. Bligh wrote:
> Is it really necessary to turn half the apic code upside down in order
> to fix this? What's the actual bugfix that's buried in this cleanup?
The way i see it is that you can't use NR_CPUS to determine the upper
bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3
but has APIC IDs of 0, 3 and 4. We need to make a distinction.
> Despite the fact you seem to have gone out of your way to make this
> hard to review, there are a few things I can see that strike me as odd.
> Not necessarily wrong, but requiring more explanation.
>
> > - if (i >= 0xf)
> > + if (i >= APIC_BROADCAST_ID)
>
> Is that always correct? it's not equivalent.
Well we really want APIC_MAX_ID (or whatever it's called)
> > - for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
> > + for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
>
> Is that the actual one-line bugfix this is all about?
No, the problem is no space for physical ids in cpumask bitmaps, this
could manifest itself later on unless we fix it now.
> > -#define APIC_BROADCAST_ID (0x0f)
> > +#define APIC_BROADCAST_ID (0xff)
>
> So ... you've tested that change on a bigsmp machine, right?
> At least, provide some reasoning here. Like this comment further down the
> patch ...
That one is slightly worrying, yes.
> > + * this isn't really broadcast, just a (potentially inaccurate) upper
> > + * bound for valid physical APIC id's
>
> Which makes the change just look wrong to me. If you're thinking
> "physical clustered mode" that terminology just utterly confusing crap,
> and the change is wrong, as far as I can see.
>
> > +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
> > 2003-07-04 02:45:17.000000000 -0700
> >
> > -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
> > +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
> > {
> > int node = apicid_to_node(logical_apicid);
> > int cpu = __ffs(logical_apicid & 0xf);
> >
> > - return cpumask_of_cpu(cpu + 4*node);
> > + return physid_mask_of_physid(cpu + 4*node);
> > }
>
> Hmmmm. What are you using physical apicids here for? They seem
> irrelevant to this function.
Urgh, it's really hard to determine what these functions really want half
the time. But that change does look wrong.
Zwane
--
function.linuxpower.ca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 16:18 ` Martin J. Bligh
@ 2003-07-04 16:16 ` Zwane Mwaikambo
2003-07-04 18:31 ` William Lee Irwin III
` (2 subsequent siblings)
3 siblings, 0 replies; 90+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04 16:16 UTC (permalink / raw)
To: Martin J. Bligh
Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
linux-kernel, linux-mm
On Fri, 4 Jul 2003, Martin J. Bligh wrote:
> > No, the problem is no space for physical ids in cpumask bitmaps, this
> > could manifest itself later on unless we fix it now.
>
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.
Hmm i hope not, Bill can you verify that? Looking at the source it doesn't
appear to be so;
#define BITS_TO_LONGS(bits) \
(((bits)+BITS_PER_LONG-1)/BITS_PER_LONG)
#define DECLARE_BITMAP(name,bits) \
unsigned long name[BITS_TO_LONGS(bits)]
> phys_cpu_present_map started off as an unsigned long, and I reused it
> in a fairly twisted way for NUMA-Q. As it's an array that's bounded
> by apic space, using the bios_cpu_apicid method that summit uses
> would be a much cleaner fix, and just leave the old one as a long
> bitmask like it used to be - which is fine for non- clustered apic
> systems, and saves inventing a whole new data type. See the
> cpu_present_to_apicid abstraction.
Thanks i'll have a look.
--
function.linuxpower.ca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 15:47 ` Zwane Mwaikambo
@ 2003-07-04 16:18 ` Martin J. Bligh
2003-07-04 16:16 ` Zwane Mwaikambo
` (3 more replies)
2003-07-04 18:29 ` William Lee Irwin III
1 sibling, 4 replies; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 16:18 UTC (permalink / raw)
To: Zwane Mwaikambo
Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
linux-kernel, linux-mm
> On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>
>> Is it really necessary to turn half the apic code upside down in order
>> to fix this? What's the actual bugfix that's buried in this cleanup?
>
> The way i see it is that you can't use NR_CPUS to determine the upper
> bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3
> but has APIC IDs of 0, 3 and 4. We need to make a distinction.
Fair enough. But that would seem to be a simpler operation than this patch.
>> > - if (i >= 0xf)
>> > + if (i >= APIC_BROADCAST_ID)
>>
>> Is that always correct? it's not equivalent.
>
> Well we really want APIC_MAX_ID (or whatever it's called)
Indeed. maybe MAX_PHYS_APIC_ID or something (it's different for logical).
We break it out in subarch, but it's the same everywhere, which seems
utterly useless - is probably historical cruft that needs to die.
But that sounds like a separate issue, and a separate patch to me.
>> > - for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
>> > + for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
>>
>> Is that the actual one-line bugfix this is all about?
>
> No, the problem is no space for physical ids in cpumask bitmaps, this
> could manifest itself later on unless we fix it now.
Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
NR_CPUS is low enough? If so, I can see more point to the patch, but
it still seems like violent overkill. Stopping it doing that would
probably fix it ... I can't imagine it buys you much.
phys_cpu_present_map started off as an unsigned long, and I reused it
in a fairly twisted way for NUMA-Q. As it's an array that's bounded
by apic space, using the bios_cpu_apicid method that summit uses
would be a much cleaner fix, and just leave the old one as a long
bitmask like it used to be - which is fine for non- clustered apic
systems, and saves inventing a whole new data type. See the
cpu_present_to_apicid abstraction.
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function.
>
> Urgh, it's really hard to determine what these functions really want half
> the time. But that change does look wrong.
Yeah, things taking logical apicids, and turning them into cpu numbers
presumably shouldn't have to touch that.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 15:41 ` Martin J. Bligh
2003-07-04 15:47 ` Zwane Mwaikambo
@ 2003-07-04 18:26 ` William Lee Irwin III
2003-07-04 19:38 ` Martin J. Bligh
1 sibling, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:26 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>>> in addition to what I hope is a fix for your bug. This uses a separate
>>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>>> APIC ID bitmaps.
>>> \begin{cross-fingers}
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is it really necessary to turn half the apic code upside down in order
> to fix this? What's the actual bugfix that's buried in this cleanup?
> Despite the fact you seem to have gone out of your way to make this
> hard to review, there are a few things I can see that strike me as odd.
> Not necessarily wrong, but requiring more explanation.
It's not a cleanup, and it doesn't touch trailing whitespace etc.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> - if (i >= 0xf)
>> + if (i >= APIC_BROADCAST_ID)
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is that always correct? it's not equivalent.
It is.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> - for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
>> + for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is that the actual one-line bugfix this is all about?
No.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
>> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
>> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:47:45.000000000 -0700
>> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
>> #define INT_DELIVERY_MODE dest_LowestPrio
>> #define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
>> -#define APIC_BROADCAST_ID (0x0f)
>> +#define APIC_BROADCAST_ID (0xff)
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> So ... you've tested that change on a bigsmp machine, right?
> At least, provide some reasoning here. Like this comment further down the
> patch ...
APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
is used in the code. That actually was commented in the patch.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> +/*
>> + * this isn't really broadcast, just a (potentially inaccurate) upper
>> + * bound for valid physical APIC id's
>> + */
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Which makes the change just look wrong to me. If you're thinking
> "physical clustered mode" that terminology just utterly confusing crap,
> and the change is wrong, as far as I can see.
The change is correct, and I am not thinking of any such thing.
APIC_BROADCAST_ID's sole usage is for terminating loops over physical
APIC ID's while setting the physical APIC ID's of IO-APIC's.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
>> 2003-07-04 02:45:17.000000000 -0700
>>
>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>> {
>> int node = apicid_to_node(logical_apicid);
>> int cpu = __ffs(logical_apicid & 0xf);
>>
>> - return cpumask_of_cpu(cpu + 4*node);
>> + return physid_mask_of_physid(cpu + 4*node);
>> }
On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Hmmmm. What are you using physical apicids here for? They seem
> irrelevant to this function.
Look at where it's used.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 15:47 ` Zwane Mwaikambo
2003-07-04 16:18 ` Martin J. Bligh
@ 2003-07-04 18:29 ` William Lee Irwin III
1 sibling, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:29 UTC (permalink / raw)
To: Zwane Mwaikambo
Cc: Martin J. Bligh, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
At some point in the past, I wrote:
>>> -#define APIC_BROADCAST_ID (0x0f)
>>> +#define APIC_BROADCAST_ID (0xff)
On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> So ... you've tested that change on a bigsmp machine, right?
>> At least, provide some reasoning here. Like this comment further down the
>> patch ...
On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> That one is slightly worrying, yes.
It is not. It's a bound on physical APIC ID's. bigsmp is xAPIC-based.
At some point in the past, I wrote:
>>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
>>> 2003-07-04 02:45:17.000000000 -0700
>>>
>>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>> {
>>> int node = apicid_to_node(logical_apicid);
>>> int cpu = __ffs(logical_apicid & 0xf);
>>>
>>> - return cpumask_of_cpu(cpu + 4*node);
>>> + return physid_mask_of_physid(cpu + 4*node);
>>> }
On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function.
On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> Urgh, it's really hard to determine what these functions really want half
> the time. But that change does look wrong.
It's fine. It's used to generate a bitmask that's or'd with
phys_cpu_present_map.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 16:18 ` Martin J. Bligh
2003-07-04 16:16 ` Zwane Mwaikambo
@ 2003-07-04 18:31 ` William Lee Irwin III
2003-07-04 19:20 ` Martin J. Bligh
2003-07-04 18:32 ` William Lee Irwin III
2003-07-04 18:36 ` William Lee Irwin III
3 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:31 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Yeah, things taking logical apicids, and turning them into cpu numbers
> presumably shouldn't have to touch that.
The bitmap is wider than the function wants. The change is fine, despite
your abuse of phys_cpu_present_map.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 16:18 ` Martin J. Bligh
2003-07-04 16:16 ` Zwane Mwaikambo
2003-07-04 18:31 ` William Lee Irwin III
@ 2003-07-04 18:32 ` William Lee Irwin III
2003-07-04 18:36 ` William Lee Irwin III
3 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:32 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.
Step off it. This is not overkill. This is correct.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 16:18 ` Martin J. Bligh
` (2 preceding siblings ...)
2003-07-04 18:32 ` William Lee Irwin III
@ 2003-07-04 18:36 ` William Lee Irwin III
3 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:36 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
At some point in the past, zwane wrote:
>> The way i see it is that you can't use NR_CPUS to determine the upper
>> bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3
>> but has APIC IDs of 0, 3 and 4. We need to make a distinction.
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Fair enough. But that would seem to be a simpler operation than this patch.
It is not a simpler operation. It is the patch.
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> We break it out in subarch, but it's the same everywhere, which seems
> utterly useless - is probably historical cruft that needs to die.
> But that sounds like a separate issue, and a separate patch to me.
The change is correct. Let it stand.
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.
This change is also correct. Let it stand.
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> phys_cpu_present_map started off as an unsigned long, and I reused it
> in a fairly twisted way for NUMA-Q. As it's an array that's bounded
> by apic space, using the bios_cpu_apicid method that summit uses
> would be a much cleaner fix, and just leave the old one as a long
> bitmask like it used to be - which is fine for non- clustered apic
> systems, and saves inventing a whole new data type. See the
> cpu_present_to_apicid abstraction.
The precise thing this does is making phys_cpu_present_map an array
bounded by the APIC space. The change is correct. Let it stand.
At some point in the past, zwane wrote:
>> Urgh, it's really hard to determine what these functions really want half
>> the time. But that change does look wrong.
On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Yeah, things taking logical apicids, and turning them into cpu numbers
> presumably shouldn't have to touch that.
The cpu bitmasks change width with NR_CPUS. The APIC ID spaces do not.
They must hence be bitmasks of separate widths. Hence the change is
correct. Let it stand.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 18:31 ` William Lee Irwin III
@ 2003-07-04 19:20 ` Martin J. Bligh
2003-07-04 19:31 ` William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:20 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
>> Yeah, things taking logical apicids, and turning them into cpu numbers
>> presumably shouldn't have to touch that.
>
> The bitmap is wider than the function wants. The change is fine, despite
> your abuse of phys_cpu_present_map.
I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
have a reason to do so. That would actually seem a much cleaner solution
to these problems than creating a whole new data type, which still doesn't
represent what it claims to
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 19:20 ` Martin J. Bligh
@ 2003-07-04 19:31 ` William Lee Irwin III
2003-07-04 19:53 ` Martin J. Bligh
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 19:31 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
At some point in the past, I wrote:
>> The bitmap is wider than the function wants. The change is fine, despite
>> your abuse of phys_cpu_present_map.
On Fri, Jul 04, 2003 at 12:20:02PM -0700, Martin J. Bligh wrote:
> I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
> have a reason to do so. That would actually seem a much cleaner solution
> to these problems than creating a whole new data type, which still doesn't
> represent what it claims to
Dirtier, but possibly lower line count.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 18:26 ` William Lee Irwin III
@ 2003-07-04 19:38 ` Martin J. Bligh
2003-07-04 20:07 ` William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:38 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>>>> in addition to what I hope is a fix for your bug. This uses a separate
>>>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>>>> APIC ID bitmaps.
>>>> \begin{cross-fingers}
>
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Is it really necessary to turn half the apic code upside down in order
>> to fix this? What's the actual bugfix that's buried in this cleanup?
>> Despite the fact you seem to have gone out of your way to make this
>> hard to review, there are a few things I can see that strike me as odd.
>> Not necessarily wrong, but requiring more explanation.
>
> It's not a cleanup, and it doesn't touch trailing whitespace etc.
Maybe not, but it looks like one. Maybe if you actually explain
what you're trying to fix, and why?
I think this kind of change deserves a better explanation that
"I'm right" ... that's my main objection.
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> - if (i >= 0xf)
>>> + if (i >= APIC_BROADCAST_ID)
>
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Is that always correct? it's not equivalent.
>
> It is.
Explain. Not obvious to the casual observer.
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
>>> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-03 12:23:56.000000000 -0700
>>> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h 2003-07-04 02:47:45.000000000 -0700
>>> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
>>> # define INT_DELIVERY_MODE dest_LowestPrio
>>> # define INT_DEST_MODE 1 /* logical delivery broadcast to all procs */
>>> -#define APIC_BROADCAST_ID (0x0f)
>>> +#define APIC_BROADCAST_ID (0xff)
>
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> So ... you've tested that change on a bigsmp machine, right?
>> At least, provide some reasoning here. Like this comment further down the
>> patch ...
>
> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
> is used in the code. That actually was commented in the patch.
I find it odd that this worked before then. Also seems to be a separate
issue from the rest of the patch. Is quite probably correct, is just
non-obvious in the context of the rest of the patch.
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> +/*
>>> + * this isn't really broadcast, just a (potentially inaccurate) upper
>>> + * bound for valid physical APIC id's
>>> + */
>
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Which makes the change just look wrong to me. If you're thinking
>> "physical clustered mode" that terminology just utterly confusing crap,
>> and the change is wrong, as far as I can see.
>
> The change is correct, and I am not thinking of any such thing.
> APIC_BROADCAST_ID's sole usage is for terminating loops over physical
> APIC ID's while setting the physical APIC ID's of IO-APIC's.
Why is Summit 0xF, and bigsmp 0xFF then?
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
>>> 2003-07-04 02:45:17.000000000 -0700
>>>
>>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>> {
>>> int node = apicid_to_node(logical_apicid);
>>> int cpu = __ffs(logical_apicid & 0xf);
>>>
>>> - return cpumask_of_cpu(cpu + 4*node);
>>> + return physid_mask_of_physid(cpu + 4*node);
>>> }
>
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function.
>
> Look at where it's used.
I did. Still unclear why you think this is correct, or what physical
apicids have to do with a function that maps from apicids to the
phys_cpu_present_map, which is a compact mapping of logical apicids
for NUMA-Q.
Sorry, but this needs more explanation.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 19:31 ` William Lee Irwin III
@ 2003-07-04 19:53 ` Martin J. Bligh
2003-07-04 20:17 ` William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:53 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
--William Lee Irwin III <wli@holomorphy.com> wrote (on Friday, July 04, 2003 12:31:35 -0700):
> At some point in the past, I wrote:
>>> The bitmap is wider than the function wants. The change is fine, despite
>>> your abuse of phys_cpu_present_map.
>
> On Fri, Jul 04, 2003 at 12:20:02PM -0700, Martin J. Bligh wrote:
>> I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
>> have a reason to do so. That would actually seem a much cleaner solution
>> to these problems than creating a whole new data type, which still doesn't
>> represent what it claims to
>
> Dirtier, but possibly lower line count.
I disagree with the "dirtier" bit, but still. I'd rather have this sort
of stuff put into subarch, where most people don't have to look at it.
More to the point, the changes would be confined to the big-iron arches,
and have less chance of breaking anyone else for things they don't
care about, nor do them any benefit. Touching this code is fragile as
hell, so if it can be confined, it should be ...
It'd also remove the long-standing abuse of phys_cpu_present_map, which
would probably make the rest of the code clearer.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 19:38 ` Martin J. Bligh
@ 2003-07-04 20:07 ` William Lee Irwin III
2003-07-04 20:37 ` Martin J. Bligh
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 20:07 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> It's not a cleanup, and it doesn't touch trailing whitespace etc.
On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Maybe not, but it looks like one. Maybe if you actually explain
> what you're trying to fix, and why?
> I think this kind of change deserves a better explanation that
> "I'm right" ... that's my main objection.
I'll try to be more verbose, then.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> It is.
On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Explain. Not obvious to the casual observer.
The function assigns physical APIC ID's to IO-APIC's. The loop is
intended to iterate over the physical APIC ID space. 0xf is an
inaccurate description of the upper bound on the physical APIC ID space.
APIC_BROADCAST_ID is a more accurate upper bound.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
>> is used in the code. That actually was commented in the patch.
On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> I find it odd that this worked before then. Also seems to be a separate
> issue from the rest of the patch. Is quite probably correct, is just
> non-obvious in the context of the rest of the patch.
I audited not only for usage of limited-width bitmaps for APIC ID
spaces, but also improper bounds on iterations over APIC ID spaces.
Things ran out of APIC ID's when phys_cpu_present_map was NR_CPUS
wide. This patch makes the limits accurate to the hardware with
the brute-force application of bitmaps. The semantic impact of
dropping in a bitmap is very low. The issue that arose was that it
wasn't wide enough, which was obvious enough to spot as a thinko
without even testing.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> The change is correct, and I am not thinking of any such thing.
>> APIC_BROADCAST_ID's sole usage is for terminating loops over physical
>> APIC ID's while setting the physical APIC ID's of IO-APIC's.
On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Why is Summit 0xF, and bigsmp 0xFF then?
Summit (and all other xAPIC-based subarches) should be 0xFF; I missed
it in the sweep.
On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> Look at where it's used.
On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> I did. Still unclear why you think this is correct, or what physical
> apicids have to do with a function that maps from apicids to the
> phys_cpu_present_map, which is a compact mapping of logical apicids
> for NUMA-Q.
> Sorry, but this needs more explanation.
The bitmap width is sufficient. NUMA-Q abuses what everything else
uses for physical APIC ID's (partly because of the BIOS). It so happens
that the array is MAX_APICS wide, which suffices for NUMA-Q (and
anything else that cares to use it).
No. This was not written for or around NUMA-Q; it's meant for the
io_apic.c loops and sparse physid wakeup on non-NUMA-Q machines.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 19:53 ` Martin J. Bligh
@ 2003-07-04 20:17 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 20:17 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote (on Friday, July 04, 2003 12:31:35 -0700):
>> Dirtier, but possibly lower line count.
On Fri, Jul 04, 2003 at 12:53:54PM -0700, Martin J. Bligh wrote:
> I disagree with the "dirtier" bit, but still. I'd rather have this sort
> of stuff put into subarch, where most people don't have to look at it.
> More to the point, the changes would be confined to the big-iron arches,
> and have less chance of breaking anyone else for things they don't
> care about, nor do them any benefit. Touching this code is fragile as
> hell, so if it can be confined, it should be ...
> It'd also remove the long-standing abuse of phys_cpu_present_map, which
> would probably make the rest of the code clearer.
That's a change with deeper semantic implications as it's relying on
different information.
The phys_cpu_present_map bits were to divorce its width from NR_CPUS
in a portable way. Shifting to bios_cpu_map[] should only change cpu
wakeup. IO-APIC physid reassignment code still needs a variable-width
map (I suppose you could use integers) of some kind.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
2003-07-04 20:07 ` William Lee Irwin III
@ 2003-07-04 20:37 ` Martin J. Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin J. Bligh @ 2003-07-04 20:37 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm
>> Maybe not, but it looks like one. Maybe if you actually explain
>> what you're trying to fix, and why?
>> I think this kind of change deserves a better explanation that
>> "I'm right" ... that's my main objection.
>
> I'll try to be more verbose, then.
Thanks ... will help a lot ;-)
> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> Explain. Not obvious to the casual observer.
>
> The function assigns physical APIC ID's to IO-APIC's. The loop is
> intended to iterate over the physical APIC ID space. 0xf is an
> inaccurate description of the upper bound on the physical APIC ID space.
> APIC_BROADCAST_ID is a more accurate upper bound.
OK, you're right. Is just confusing because it works as it is right
now ... even on a 32x system - however, that's only because Summit
doesn't actually run that region of code, and NUMA-Q ignores it.
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
>>> is used in the code. That actually was commented in the patch.
>
> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> I find it odd that this worked before then. Also seems to be a separate
>> issue from the rest of the patch. Is quite probably correct, is just
>> non-obvious in the context of the rest of the patch.
>
> I audited not only for usage of limited-width bitmaps for APIC ID
> spaces, but also improper bounds on iterations over APIC ID spaces.
> Things ran out of APIC ID's when phys_cpu_present_map was NR_CPUS
> wide. This patch makes the limits accurate to the hardware with
> the brute-force application of bitmaps. The semantic impact of
> dropping in a bitmap is very low. The issue that arose was that it
> wasn't wide enough, which was obvious enough to spot as a thinko
> without even testing.
>
>> Why is Summit 0xF, and bigsmp 0xFF then?
>
> Summit (and all other xAPIC-based subarches) should be 0xFF; I missed
> it in the sweep.
OK. Makes more sense now if both are that way.
> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> Look at where it's used.
>
> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> I did. Still unclear why you think this is correct, or what physical
>> apicids have to do with a function that maps from apicids to the
>> phys_cpu_present_map, which is a compact mapping of logical apicids
>> for NUMA-Q.
>> Sorry, but this needs more explanation.
>
> The bitmap width is sufficient. NUMA-Q abuses what everything else
> uses for physical APIC ID's (partly because of the BIOS). It so happens
> that the array is MAX_APICS wide, which suffices for NUMA-Q (and
> anything else that cares to use it).
>
> No. This was not written for or around NUMA-Q; it's meant for the
> io_apic.c loops and sparse physid wakeup on non-NUMA-Q machines.
OK, maybe this is just an extension of my earlier abuse - in which
case, let's just remove it. Was bad enough before, but now even I
can't understand it, and I wrote the damned thing.
So yes, it looks correct. I'll see if I can see a neat way to bury this
under the existing abstractions like Summit does ... I'm not sure it's
a good idea to have two different methods for this; that whole area of
code is getting horribly complicated ...
Thanks very much for the explanations,
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (5 preceding siblings ...)
2003-07-04 8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
@ 2003-07-04 21:07 ` William Lee Irwin III
2003-07-05 1:15 ` 2.5.74-mm1 Andrew Morton
2003-07-05 0:16 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
8 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-04 21:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm
On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
anton saw the OOM killer try to kill pdflush, causing tons of spurious
wakeups. This should avoid picking kernel threads in select_bad_process().
-- wli
===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c Fri Jul 4 14:03:32 2003
@@ -123,7 +123,7 @@
struct task_struct *chosen = NULL;
do_each_thread(g, p)
- if (p->pid) {
+ if (p->pid && p->mm) {
int points = badness(p);
if (points > maxpoints) {
chosen = p;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (6 preceding siblings ...)
2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 0:16 ` Daniel Phillips
2003-07-05 15:28 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
8 siblings, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-05 0:16 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
On Thursday 03 July 2003 11:37, Andrew Morton wrote:
> . Included Con's CPU scheduler changes. Feedback on the effectiveness of
> this and the usual benchmarks would be interesting.
>
> Changes to the CPU scheduler tend to cause surprising and subtle problems
> in areas where you least expect it, and these do take a long time to
> materialise. Alterations in there need to be made carefully and
> cautiously. We shall see...
It now tolerates window dragging on this unaccelerated moderately high
resolution VGA without any sound dropouts. There are still dropouts while
scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as expected.
I had 2.5.74 freeze up a couple of times yesterday, resulting in a totally
dead, unpingable system, so now I'm running 2.5.74-mm1 with kgdb and hoping
to catch one of those beasts in the wild. The most recent incident occurred
while switching from X to text console, which did not complete, leaving me
with no debugging data whatsover. That was with sound running. Switching to
the text console always results in a massive sound skip, so there is a clue.
XFree is running generic VGA, so I don't seriously suspect the driver, and
even so, it should not be able to kill the system completely dead.
System details are as I reported earlier:
AMD K7 1666 (actual) MHz, 512 MB, VIA VTxxx chipset. Video hardware is
S3 ProSavage K4M266, unaccelerated VGA mode, 1280x1024x16. Software is
2.5.73+Gnome+Metacity+ALSA+Zinf. Running UP, no preempt.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 1:15 ` Andrew Morton
2003-07-05 5:21 ` 2.5.74-mm1 Anton Blanchard
2003-07-05 10:44 ` 2.5.74-mm1 William Lee Irwin III
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2003-07-05 1:15 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
>
> anton saw the OOM killer try to kill pdflush, causing tons of spurious
> wakeups. This should avoid picking kernel threads in select_bad_process().
>
>
> -- wli
>
>
> ===== mm/oom_kill.c 1.23 vs edited =====
> --- 1.23/mm/oom_kill.c Wed Apr 23 03:15:53 2003
> +++ edited/mm/oom_kill.c Fri Jul 4 14:03:32 2003
> @@ -123,7 +123,7 @@
> struct task_struct *chosen = NULL;
>
> do_each_thread(g, p)
> - if (p->pid) {
> + if (p->pid && p->mm) {
> int points = badness(p);
> if (points > maxpoints) {
> chosen = p;
Look at select_bad_process(), and the ->mm test in badness(). pdflush
can never be chosen.
Nevertheless, there have been several report where kernel threads _are_
being hit my the oom killer. Any idea why that is?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 1:15 ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 5:21 ` Anton Blanchard
2003-07-05 11:18 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 10:44 ` 2.5.74-mm1 William Lee Irwin III
1 sibling, 1 reply; 90+ messages in thread
From: Anton Blanchard @ 2003-07-05 5:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: William Lee Irwin III, linux-kernel, linux-mm
> Look at select_bad_process(), and the ->mm test in badness(). pdflush
> can never be chosen.
>
> Nevertheless, there have been several report where kernel threads _are_
> being hit my the oom killer. Any idea why that is?
Milton and I were just looking at this and it seems there is no locking
to prevent p->mm ending up NULL due to exit. And if p->mm does end up
NULL, you go off and kill all your kernel threads :)
Anton
read_lock(&tasklist_lock);
p = select_bad_process();
...
oom_kill_task(p);
/*
* kill all processes that share the ->mm (i.e. all threads),
* but are in a different thread group
*/
do_each_thread(g, q)
if (q->mm == p->mm && q->tgid != p->tgid)
oom_kill_task(q);
while_each_thread(g, q);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 1:15 ` 2.5.74-mm1 Andrew Morton
2003-07-05 5:21 ` 2.5.74-mm1 Anton Blanchard
@ 2003-07-05 10:44 ` William Lee Irwin III
2003-07-05 18:43 ` 2.5.74-mm1 Andrew Morton
1 sibling, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-05 10:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm
On Fri, Jul 04, 2003 at 06:15:39PM -0700, Andrew Morton wrote:
> Look at select_bad_process(), and the ->mm test in badness(). pdflush
> can never be chosen.
> Nevertheless, there have been several report where kernel threads _are_
> being hit my the oom killer. Any idea why that is?
The badness() check isn't good enough. If badness() returns 0 for all
processes with pid's > 0 and the first one seen is a kernel thread the
kernel thread will be chosen. In principle, one could merely retarget
chosen with points >= maxpoints, but that's trivially defeated by
kernel threads landing at the highest pid for whatever reason.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 5:21 ` 2.5.74-mm1 Anton Blanchard
@ 2003-07-05 11:18 ` William Lee Irwin III
2003-07-05 11:46 ` 2.5.74-mm1 William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-05 11:18 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Andrew Morton, linux-kernel, linux-mm
At some point in the past, akpm wrote:
>> Look at select_bad_process(), and the ->mm test in badness(). pdflush
>> can never be chosen.
>> Nevertheless, there have been several report where kernel threads _are_
>> being hit my the oom killer. Any idea why that is?
On Sat, Jul 05, 2003 at 03:21:02PM +1000, Anton Blanchard wrote:
> Milton and I were just looking at this and it seems there is no locking
> to prevent p->mm ending up NULL due to exit. And if p->mm does end up
> NULL, you go off and kill all your kernel threads :)
How about this, then? I think it's still racy against something doing
daemonize(), though (i.e. if q does daemonize() it shoots it regardless).
===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c Sat Jul 5 04:15:25 2003
@@ -123,7 +123,7 @@
struct task_struct *chosen = NULL;
do_each_thread(g, p)
- if (p->pid) {
+ if (p->pid && p->mm) {
int points = badness(p);
if (points > maxpoints) {
chosen = p;
@@ -141,7 +141,7 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
{
printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
@@ -161,6 +161,15 @@
}
}
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+ struct mm_struct *mm = get_task_mm(p);
+ if (!mm || mm == &init_mm)
+ return NULL;
+ __oom_kill_task(p);
+}
+
+
/**
* oom_kill - kill the "best" process when we run out of memory
*
@@ -171,9 +180,11 @@
*/
static void oom_kill(void)
{
+ struct mm_struct *mm;
struct task_struct *g, *p, *q;
read_lock(&tasklist_lock);
+retry:
p = select_bad_process();
/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +193,20 @@
panic("Out of memory and no killable processes...\n");
}
- oom_kill_task(p);
+ mm = oom_kill_task(p);
+ if (!mm)
+ goto retry;
/*
* kill all processes that share the ->mm (i.e. all threads),
* but are in a different thread group
*/
do_each_thread(g, q)
- if (q->mm == p->mm && q->tgid != p->tgid)
- oom_kill_task(q);
+ if (q->mm == mm && q->tgid != p->tgid)
+ __oom_kill_task(q);
while_each_thread(g, q);
read_unlock(&tasklist_lock);
+ mmput(mm);
/*
* Make kswapd go out of the way, so "p" has a good chance of
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 11:18 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 11:46 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-05 11:46 UTC (permalink / raw)
To: Anton Blanchard, Andrew Morton, linux-kernel, linux-mm
On Sat, Jul 05, 2003 at 04:18:44AM -0700, William Lee Irwin III wrote:
> How about this, then? I think it's still racy against something doing
> daemonize(), though (i.e. if q does daemonize() it shoots it regardless).
Take 2:
===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c Sat Jul 5 04:46:17 2003
@@ -123,7 +123,7 @@
struct task_struct *chosen = NULL;
do_each_thread(g, p)
- if (p->pid) {
+ if (p->pid && p->mm) {
int points = badness(p);
if (points > maxpoints) {
chosen = p;
@@ -141,7 +141,7 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
{
printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
@@ -161,6 +161,16 @@
}
}
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+ struct mm_struct *mm = get_task_mm(p);
+ if (!mm || mm == &init_mm)
+ return NULL;
+ __oom_kill_task(p);
+ return mm;
+}
+
+
/**
* oom_kill - kill the "best" process when we run out of memory
*
@@ -171,9 +181,11 @@
*/
static void oom_kill(void)
{
+ struct mm_struct *mm;
struct task_struct *g, *p, *q;
read_lock(&tasklist_lock);
+retry:
p = select_bad_process();
/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +194,20 @@
panic("Out of memory and no killable processes...\n");
}
- oom_kill_task(p);
+ mm = oom_kill_task(p);
+ if (!mm)
+ goto retry;
/*
* kill all processes that share the ->mm (i.e. all threads),
* but are in a different thread group
*/
do_each_thread(g, q)
- if (q->mm == p->mm && q->tgid != p->tgid)
- oom_kill_task(q);
+ if (q->mm == mm && q->tgid != p->tgid)
+ __oom_kill_task(q);
while_each_thread(g, q);
read_unlock(&tasklist_lock);
+ mmput(mm);
/*
* Make kswapd go out of the way, so "p" has a good chance of
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 0:16 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 15:28 ` Daniel Phillips
2003-07-05 16:01 ` 2.5.74-mm1 Con Kolivas
2003-07-05 19:14 ` 2.5.74-mm1 Andrew Morton
0 siblings, 2 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-05 15:28 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
On Saturday 05 July 2003 02:16, Daniel Phillips wrote:
> It now tolerates window dragging on this unaccelerated moderately high
> resolution VGA without any sound dropouts. There are still dropouts while
> scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as expected.
Update: dropouts still do occur while moving windows, but rarely. When they
do occur, they are severe. A debian dist-upgrade just caused a dropout - and
another just now, about 3 seconds long. I feel that tweaking is only going
to get us so far with this. The situation re scheduling in 2.5 feels much as
the vm situation did in 2.3, in other words, we're halfway down a long twisty
road that ends with something that works, after having tried and failed at
many flavors of tweaking and tuning. Ultimately the problem will be solved
by redesign, and probably not just limited to kernel code.
> I had 2.5.74 freeze up a couple of times yesterday, resulting in a totally
> dead, unpingable system, so now I'm running 2.5.74-mm1 with kgdb and hoping
> to catch one of those beasts in the wild.
Update: this is easily repeatable. A few quick switches between X and text
mode triggers the freeze reliably. On two occasions, I had a lockup while
just doing an innocent window operation. It also happens in 2.4, so it isn't
a 2.5 problem per se. Is it a pure hardware problem? It's always easy to
take that position. I can only guess at the moment. Kgdb is no help in
diagnosing, as the kgdb stub also goes comatose, or at least the serial link
does. No lockups have occurred so far when I was not interacting with the
system via the keyboard or mouse. Suggestions?
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 15:28 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 16:01 ` Con Kolivas
2003-07-05 17:47 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 19:14 ` 2.5.74-mm1 Andrew Morton
1 sibling, 1 reply; 90+ messages in thread
From: Con Kolivas @ 2003-07-05 16:01 UTC (permalink / raw)
To: Daniel Phillips, Andrew Morton, linux-kernel, linux-mm
On Sun, 6 Jul 2003 01:28, Daniel Phillips wrote:
> On Saturday 05 July 2003 02:16, Daniel Phillips wrote:
> > It now tolerates window dragging on this unaccelerated moderately high
> > resolution VGA without any sound dropouts. There are still dropouts
> > while scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as
> > expected.
>
> Update: dropouts still do occur while moving windows, but rarely. When
> they do occur, they are severe. A debian dist-upgrade just caused a
> dropout - and another just now, about 3 seconds long. I feel that tweaking
> is only going to get us so far with this. The situation re scheduling in
> 2.5 feels much as the vm situation did in 2.3, in other words, we're
> halfway down a long twisty road that ends with something that works, after
> having tried and failed at many flavors of tweaking and tuning. Ultimately
> the problem will be solved by redesign, and probably not just limited to
> kernel code.
Have you taken the next twist in the road? I posted a second patch which
should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in case,
here is a link to it.
http://kernel.kolivas.org/2.5/
it's called patch-O2int-0307041440
It makes significant headway in smoothing the corner cases. I need testing at
each point before I can post another update, and am doing much less frequent
smaller updates now, with the aim of having no more than one patch for each
-mm, so I can have a decent sized audience for each change.
Andrew can you please apply this one on top in the next -mm if you are to
continue testing this patch series.
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 16:01 ` 2.5.74-mm1 Con Kolivas
@ 2003-07-05 17:47 ` Daniel Phillips
2003-07-06 3:41 ` 2.5.74-mm1 Con Kolivas
0 siblings, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-05 17:47 UTC (permalink / raw)
To: Con Kolivas, Andrew Morton, linux-kernel, linux-mm
On Saturday 05 July 2003 18:01, Con Kolivas wrote:
> Have you taken the next twist in the road? I posted a second patch which
> should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in
> case, here is a link to it.
>
> http://kernel.kolivas.org/2.5/
>
> it's called patch-O2int-0307041440
This one is a regression. Window dragging now causes the same kind of
dropouts as I saw on 2.5.73 mainline. But see below.
> It makes significant headway in smoothing the corner cases. I need testing
> at each point before I can post another update, and am doing much less
> frequent smaller updates now, with the aim of having no more than one patch
> for each -mm, so I can have a decent sized audience for each change.
>
> Andrew can you please apply this one on top in the next -mm if you are to
> continue testing this patch series.
Well...
It should help you to know that up till now I've been running Zinf at priority
0 (of -20..19). I just changed change that to -10, and all the dropouts went
away. Duh. The thing is, Zinf is a (soft) realtime application, or at least
the sound servicing part of it is. It's hard to see how the kernel can ever
figure that out automagically - it has to be told. So I told it.
My only reservation is that nice is not a very (ahem) nice way of doing this.
We really want Zinf to take care of that itself. Zinf knows it has a
realtime component and it knows which component that is, so it needs to tell
the kernel, presumeably via setpriority (nice is just a frontend to
setpriority). Blindly choosing some higher priority to run at is certainly
crude, but for now it solves the problem, so I won't have to apologize to my
wife about destroying her audio experience with the latest, greatest kernel.
Not having to worry about detecting and babying along the realtime sound
thread should make your job considerably easier. OK, looking at the Zinf
code I see that it does know about thread priority, via pthreads. It's
either not working, or it's not set to sensible defaults. I'm looking into
that.
Now, just so this doesn't get too easy for you, I have a nice little opengl
application here:
http://nl.linux.org/~phillips/world.tgz
(3D engine - see screenshots on the same page)
The "bounce" demo is suitable for testing how steady the framerate is. It's
working pretty well since 2.4.73, if you leave the window in one place, but
scheduling gets challenging (i.e., sucks) when you drag the 3D window around.
How should we fix that? It's my code so I'm willing to add whatever priority
control is appropriate.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 10:44 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 18:43 ` Andrew Morton
2003-07-05 21:17 ` 2.5.74-mm1 William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2003-07-05 18:43 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> The badness() check isn't good enough. If badness() returns 0 for all
> processes with pid's > 0 and the first one seen is a kernel thread the
> kernel thread will be chosen.
Are we looking at the same code?
static struct task_struct * select_bad_process(void)
{
int maxpoints = 0;
struct task_struct *g, *p;
struct task_struct *chosen = NULL;
do_each_thread(g, p)
if (p->pid) {
int points = badness(p);
if (points > maxpoints) {
chosen = p;
maxpoints = points;
}
if (p->flags & PF_SWAPOFF)
return p;
}
while_each_thread(g, p);
return chosen;
}
if badness() returns zero for everything, this returns NULL and
the kernel panics.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 15:28 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 16:01 ` 2.5.74-mm1 Con Kolivas
@ 2003-07-05 19:14 ` Andrew Morton
2003-07-05 21:09 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 0:10 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2003-07-05 19:14 UTC (permalink / raw)
To: Daniel Phillips; +Cc: linux-kernel, linux-mm
Daniel Phillips <phillips@arcor.de> wrote:
>
> The situation re scheduling in 2.5 feels much as
> the vm situation did in 2.3
I've been trying to avoid thinking about that comparison.
I don't think it's really, really bad at present. Just "should be a bit
better".
> Kgdb is no help in
> diagnosing, as the kgdb stub also goes comatose, or at least the serial link
> does. No lockups have occurred so far when I was not interacting with the
> system via the keyboard or mouse. Suggestions?
Enable IO APIC, Local APIC, nmi watchdog. Use serial console, see if you
can get a sysrq trace out of it. That's `^A F T' in minicom.
I mean, it _has_ to be either stuck with interrupts on, or stuck with them off.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 19:14 ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 21:09 ` Daniel Phillips
2003-07-05 21:44 ` 2.5.74-mm1 Jamie Lokier
2003-07-06 0:10 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-05 21:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > The situation re scheduling in 2.5 feels much as
> > the vm situation did in 2.3
>
> I've been trying to avoid thinking about that comparison.
>
> I don't think it's really, really bad at present. Just "should be a bit
> better".
Ever since I -niced Zinf a coupld of hours ago I haven't had a problem. This
is a fine way to handle the problem. We're not dealing with an "interactive
scheduling" problem here, it's simply realtime scheduling and needs to be
treated as such.
Unfortunately, negative priority requires root privilege, at least on Debian.
That's dumb. By default, the root privilege requirement should kick in at
something like -5 or -10, so ordinary users can set priorities higher than
the default, as well as lower. For the millions of desktop users out there,
sound ought to work by default, not be broken by default.
The "better" mechanism for sound scheduling is SCHED_RR, which requires root
privilege for some reason that isn't clear to me. Or maybe there once was a
good reason, back in the days of the dinosaurs.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 18:43 ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 21:17 ` William Lee Irwin III
2003-07-05 21:27 ` 2.5.74-mm1 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-05 21:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm
On Sat, Jul 05, 2003 at 11:43:08AM -0700, Andrew Morton wrote:
> if badness() returns zero for everything, this returns NULL and
> the kernel panics.
Sorry, that was one hell of an oversight wrt. the initival value.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 21:17 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 21:27 ` Andrew Morton
2003-07-05 22:03 ` 2.5.74-mm1 William Lee Irwin III
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2003-07-05 21:27 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Sat, Jul 05, 2003 at 11:43:08AM -0700, Andrew Morton wrote:
> > if badness() returns zero for everything, this returns NULL and
> > the kernel panics.
>
> Sorry, that was one hell of an oversight wrt. the initival value.
You made me read that code about 20 times ;)
Still. Do we think we know what the actual bug is? That tasklist_lock
doesn't pin tsk->mm?
If so then let's get that patch of yours happening, but please enhance it to
a) detect the situation where the mm went away, and tell us that it was
fixed up. Sufficient to confirm your theory.
b) put in an explicit check for a kill of an mm-less process. print a
warning, skip the process.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 21:09 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 21:44 ` Jamie Lokier
2003-07-05 22:10 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 1 reply; 90+ messages in thread
From: Jamie Lokier @ 2003-07-05 21:44 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Andrew Morton, linux-kernel, linux-mm
Daniel Phillips wrote:
> Unfortunately, negative priority requires root privilege, at least
> on Debian.
>
> That's dumb. By default, the root privilege requirement should kick
> in at something like -5 or -10, so ordinary users can set priorities
> higher than the default, as well as lower. For the millions of
> desktop users out there, sound ought to work by default, not be
> broken by default.
The security problem, on a multi-user box, is that negative priority
apps can easily take all of the CPU and effectively lock up the box.
Something I've often thought would fix this is to allow normal users
to set negative priority which is limited to using X% of the CPU -
i.e. those tasks would have their priority raised if they spent more
than a small proportion of their time using the CPU.
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 21:27 ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 22:03 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-05 22:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>> Sorry, that was one hell of an oversight wrt. the initival value.
On Sat, Jul 05, 2003 at 02:27:52PM -0700, Andrew Morton wrote:
> You made me read that code about 20 times ;)
> Still. Do we think we know what the actual bug is? That tasklist_lock
> doesn't pin tsk->mm?
> If so then let's get that patch of yours happening, but please enhance it to
> a) detect the situation where the mm went away, and tell us that it was
> fixed up. Sufficient to confirm your theory.
> b) put in an explicit check for a kill of an mm-less process. print a
> warning, skip the process.
exit_mm() is excluded by the task_lock(), so p->mm (or any of the
others) can vanish at any time (the callers don't hold the tasklist_lock
either). So did you have in mind something like this?
-- wli
===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c Sat Jul 5 15:00:15 2003
@@ -141,8 +141,16 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
{
+ task_lock(p);
+ if (!p->mm || p->mm == &init_mm) {
+ WARN_ON(1);
+ printk(KERN_WARNING "tried to kill an mm-less task!\n");
+ task_unlock(p);
+ return;
+ }
+ task_unlock(p);
printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
/*
@@ -161,6 +169,16 @@
}
}
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+ struct mm_struct *mm = get_task_mm(p);
+ if (!mm || mm == &init_mm)
+ return NULL;
+ __oom_kill_task(p);
+ return mm;
+}
+
+
/**
* oom_kill - kill the "best" process when we run out of memory
*
@@ -171,9 +189,11 @@
*/
static void oom_kill(void)
{
+ struct mm_struct *mm;
struct task_struct *g, *p, *q;
read_lock(&tasklist_lock);
+retry:
p = select_bad_process();
/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +202,21 @@
panic("Out of memory and no killable processes...\n");
}
- oom_kill_task(p);
+ mm = oom_kill_task(p);
+ if (!mm)
+ goto retry;
/*
* kill all processes that share the ->mm (i.e. all threads),
* but are in a different thread group
*/
do_each_thread(g, q)
- if (q->mm == p->mm && q->tgid != p->tgid)
- oom_kill_task(q);
+ if (q->mm == mm && q->tgid != p->tgid)
+ __oom_kill_task(q);
while_each_thread(g, q);
-
+ if (!p->mm)
+ printk(KERN_INFO "Fixed up OOM kill of mm-less task\n");
read_unlock(&tasklist_lock);
+ mmput(mm);
/*
* Make kswapd go out of the way, so "p" has a good chance of
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 21:44 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-05 22:10 ` Daniel Phillips
2003-07-06 1:28 ` 2.5.74-mm1 Jamie Lokier
0 siblings, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-05 22:10 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Andrew Morton, linux-kernel, linux-mm
On Saturday 05 July 2003 23:44, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > Unfortunately, negative priority requires root privilege, at least
> > on Debian.
> >
> > That's dumb. By default, the root privilege requirement should kick
> > in at something like -5 or -10, so ordinary users can set priorities
> > higher than the default, as well as lower. For the millions of
> > desktop users out there, sound ought to work by default, not be
> > broken by default.
>
> The security problem, on a multi-user box, is that negative priority
> apps can easily take all of the CPU and effectively lock up the box.
I don't see that: the solution is to set the niceness any essential process
more negative than is possible for a normal user, which is just what we have
now. The stupid thing is the making the most negative possible and the
default niceness the same. What are you going to do if you have one
application you want to take priority, re-nice the other 50?
An alternate solution is to allow the user to specify the default niceness.
For all I know, there is such a way. If not, there ought to be, and it
should be higher than the superuser cutoff by default. Then the sound app
will come along and grab the highest priority it can, and it will actually
succeed in obtaining a higher priority than garden variety processes, which
is not what happens now.
> Something I've often thought would fix this is to allow normal users
> to set negative priority which is limited to using X% of the CPU -
> i.e. those tasks would have their priority raised if they spent more
> than a small proportion of their time using the CPU.
That's essentially SCHED_RR. As I mentioned above, it's not clear to me why
SCHED_RR requires superuser privilege, since the amount of CPU you can burn
that way is bounded. Well, the total of all SCHED_RR processes would need to
be bounded as well, which is straightforward.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 19:14 ` 2.5.74-mm1 Andrew Morton
2003-07-05 21:09 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06 0:10 ` Daniel Phillips
2003-07-06 0:10 ` 2.5.74-mm1 Davide Libenzi
1 sibling, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-06 0:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > Kgdb is no help in
> > diagnosing, as the kgdb stub also goes comatose, or at least the serial
> > link does. No lockups have occurred so far when I was not interacting
> > with the system via the keyboard or mouse. Suggestions?
>
> Enable IO APIC, Local APIC, nmi watchdog. Use serial console, see if you
> can get a sysrq trace out of it. That's `^A F T' in minicom.
OK, tried that. Still very dead.
> I mean, it _has_ to be either stuck with interrupts on, or stuck with them
> off.
Interesting data: it always hangs on the 4th iteration of Ctrl-Alt-F7,
Ctrl-Alt-F2. This smells like a bios stack overflow. I think I'd better go
poke at the vendor at this point, no?
I do feel Linux is exonerated, but then this just shows why we need to keep on
moving, right on into the bios.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 0:10 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06 0:10 ` Davide Libenzi
0 siblings, 0 replies; 90+ messages in thread
From: Davide Libenzi @ 2003-07-06 0:10 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm
On Sun, 6 Jul 2003, Daniel Phillips wrote:
> On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> > Daniel Phillips <phillips@arcor.de> wrote:
> > > Kgdb is no help in
> > > diagnosing, as the kgdb stub also goes comatose, or at least the serial
> > > link does. No lockups have occurred so far when I was not interacting
> > > with the system via the keyboard or mouse. Suggestions?
> >
> > Enable IO APIC, Local APIC, nmi watchdog. Use serial console, see if you
> > can get a sysrq trace out of it. That's `^A F T' in minicom.
>
> OK, tried that. Still very dead.
Last resort, LKCD ;)
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 22:10 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06 1:28 ` Jamie Lokier
2003-07-06 2:14 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 1 reply; 90+ messages in thread
From: Jamie Lokier @ 2003-07-06 1:28 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Andrew Morton, linux-kernel, linux-mm
Daniel Phillips wrote:
> What are you going to do if you have one
> application you want to take priority, re-nice the other 50?
Is that effective? It might be just the trick.
> > Something I've often thought would fix this is to allow normal users
> > to set negative priority which is limited to using X% of the CPU -
> > i.e. those tasks would have their priority raised if they spent more
> > than a small proportion of their time using the CPU.
>
> That's essentially SCHED_RR. As I mentioned above, it's not clear
> to me why SCHED_RR requires superuser privilege, since the amount of
> CPU you can burn that way is bounded. Well, the total of all
> SCHED_RR processes would need to be bounded as well, which is
> straightforward.
Your last point is most important. At the moment, a SCHED_RR process
with a bug will basically lock up the machine, which is totally
inappropriate for a user app.
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 1:28 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-06 2:14 ` Daniel Phillips
2003-07-06 2:21 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 10:00 ` 2.5.74-mm1 Mel Gorman
0 siblings, 2 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-06 2:14 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Andrew Morton, linux-kernel, linux-mm
On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > What are you going to do if you have one
> > application you want to take priority, re-nice the other 50?
>
> Is that effective? It might be just the trick.
Point.
> > > Something I've often thought would fix this is to allow normal users
> > > to set negative priority which is limited to using X% of the CPU -
> > > i.e. those tasks would have their priority raised if they spent more
> > > than a small proportion of their time using the CPU.
> >
> > That's essentially SCHED_RR. As I mentioned above, it's not clear
> > to me why SCHED_RR requires superuser privilege, since the amount of
> > CPU you can burn that way is bounded. Well, the total of all
> > SCHED_RR processes would need to be bounded as well, which is
> > straightforward.
>
> Your last point is most important. At the moment, a SCHED_RR process
> with a bug will basically lock up the machine, which is totally
> inappropriate for a user app.
How does the lockup come about? As defined, a single SCHED_RR process could
lock up only its own slice of CPU, as far as I can see.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 2:14 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06 2:21 ` Davide Libenzi
2003-07-06 13:54 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 10:00 ` 2.5.74-mm1 Mel Gorman
1 sibling, 1 reply; 90+ messages in thread
From: Davide Libenzi @ 2003-07-06 2:21 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List, linux-mm
On Sun, 6 Jul 2003, Daniel Phillips wrote:
> On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> >
> > Your last point is most important. At the moment, a SCHED_RR process
> > with a bug will basically lock up the machine, which is totally
> > inappropriate for a user app.
>
> How does the lockup come about? As defined, a single SCHED_RR process could
> lock up only its own slice of CPU, as far as I can see.
They're de-queued and re-queue in the active array w/out having dynamic
priority adjustment (like POSIX states). This means that any task with
lower priority will starve if the RR task will not release the CPU.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-05 17:47 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06 3:41 ` Con Kolivas
2003-07-06 18:50 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 1 reply; 90+ messages in thread
From: Con Kolivas @ 2003-07-06 3:41 UTC (permalink / raw)
To: Daniel Phillips, Andrew Morton, linux-kernel, linux-mm
On Sun, 6 Jul 2003 03:47, Daniel Phillips wrote:
> On Saturday 05 July 2003 18:01, Con Kolivas wrote:
> > Have you taken the next twist in the road? I posted a second patch which
> > should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in
> > case, here is a link to it.
> >
> > http://kernel.kolivas.org/2.5/
> >
> > it's called patch-O2int-0307041440
>
> This one is a regression. Window dragging now causes the same kind of
> dropouts as I saw on 2.5.73 mainline. But see below.
X is still getting sustained priority in this one; This version addressed
other more important issues. The next version may help when I've made it.
>
> > It makes significant headway in smoothing the corner cases. I need
> > testing at each point before I can post another update, and am doing much
> > less frequent smaller updates now, with the aim of having no more than
> > one patch for each -mm, so I can have a decent sized audience for each
> > change.
> >
> > Andrew can you please apply this one on top in the next -mm if you are to
> > continue testing this patch series.
>
> Well...
>
> It should help you to know that up till now I've been running Zinf at
> priority 0 (of -20..19). I just changed change that to -10, and all the
> dropouts went away. Duh. The thing is, Zinf is a (soft) realtime
> application, or at least the sound servicing part of it is. It's hard to
> see how the kernel can ever figure that out automagically - it has to be
> told. So I told it.
>
> My only reservation is that nice is not a very (ahem) nice way of doing
> this. We really want Zinf to take care of that itself. Zinf knows it has a
> realtime component and it knows which component that is, so it needs to
> tell the kernel, presumeably via setpriority (nice is just a frontend to
> setpriority). Blindly choosing some higher priority to run at is certainly
> crude, but for now it solves the problem, so I won't have to apologize to
> my wife about destroying her audio experience with the latest, greatest
> kernel.
>
> Not having to worry about detecting and babying along the realtime sound
> thread should make your job considerably easier. OK, looking at the Zinf
> code I see that it does know about thread priority, via pthreads. It's
> either not working, or it's not set to sensible defaults. I'm looking into
> that.
Well if it gets real time scheduling all that goes away.. But of course that
would mean it needs root or equivalent user access. Even the lowest priority
real time apps get scheduled ahead of any nice priority boosted or
interactive boosted normal scheduling apps. However I'm going to give X less
buffer in the next version so it should get better without RT scheduling.
WRT the other lkml threads, audio should work without skips on normal desktop
loads without priority changes, without root privileges and without RT
scheduling. Therefore I am still considering it a regression.
>
> Now, just so this doesn't get too easy for you, I have a nice little opengl
> application here:
>
> http://nl.linux.org/~phillips/world.tgz
> (3D engine - see screenshots on the same page)
>
> The "bounce" demo is suitable for testing how steady the framerate is.
> It's working pretty well since 2.4.73, if you leave the window in one
> place, but scheduling gets challenging (i.e., sucks) when you drag the 3D
> window around. How should we fix that? It's my code so I'm willing to add
> whatever priority control is appropriate.
I assume you're not asking for the scheduler to be tweaked for this. You want
the 3d rendering to occur regardless of what is happening anywhere else? If
it doesn't use much cpu time but wakes lots then in it's current form the
scheduler will happily put this equal sharing with everything at nice 0. X
intermittently gets cpu hungry so will make this slow down at the moment
during those bursts. Your app will go ahead of everything else at a priority
of -3.
If it is cpu hungry, it will need at least -8 to get in on the act, and -13 to
be ahead of everyone (not really recommended though).
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 2:21 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-06 13:54 ` Daniel Phillips
0 siblings, 0 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-06 13:54 UTC (permalink / raw)
To: Davide Libenzi
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List, linux-mm
On Sunday 06 July 2003 04:21, Davide Libenzi wrote:
> On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> > > Your last point is most important. At the moment, a SCHED_RR process
> > > with a bug will basically lock up the machine, which is totally
> > > inappropriate for a user app.
> >
> > How does the lockup come about? As defined, a single SCHED_RR process
> > could lock up only its own slice of CPU, as far as I can see.
>
> They're de-queued and re-queue in the active array w/out having dynamic
> priority adjustment (like POSIX states). This means that any task with
> lower priority will starve if the RR task will not release the CPU.
OK, I see, I didn't pay close enough attention to the "it will be put at the
end of the list _for its priority_" part.
So SCHED_RR is broken by design, too bad. Now, how would SCHED_RR_NOTBROKEN
work?
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 3:41 ` 2.5.74-mm1 Con Kolivas
@ 2003-07-06 18:50 ` Daniel Phillips
0 siblings, 0 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-06 18:50 UTC (permalink / raw)
To: Con Kolivas, Andrew Morton, linux-kernel, linux-mm
On Sunday 06 July 2003 05:41, Con Kolivas wrote:
> On Sun, 6 Jul 2003 03:47, Daniel Phillips wrote:
> > Not having to worry about detecting and babying along the realtime sound
> > thread should make your job considerably easier. OK, looking at the Zinf
> > code I see that it does know about thread priority, via pthreads. It's
> > either not working, or it's not set to sensible defaults. I'm looking
> > into that.
>
> Well if it gets real time scheduling all that goes away.. But of course
> that would mean it needs root or equivalent user access.
We need to do something about that, apparently. OK, in another thread it's
been pointed out that SCHED_RR is broken for this, but nice=-something is
still an option.
> Even the lowest
> priority real time apps get scheduled ahead of any nice priority boosted or
> interactive boosted normal scheduling apps. However I'm going to give X
> less buffer in the next version so it should get better without RT
> scheduling.
>
> WRT the other lkml threads, audio should work without skips on normal
> desktop loads without priority changes, without root privileges and without
> RT scheduling. Therefore I am still considering it a regression.
Given that my sound is now working better for me than it ever has on any
version of Linux, I wouldn't be so fast to call it a regression. The active
ingredient is a priori priority assignment. With your patch, nice=-2 gives
solid, reliable sound playing under all conditions I've thought to try.
Without your patch, nice=-10 is insufficient. So you're on to something
good, it seems.
> > Now, just so this doesn't get too easy for you, I have a nice little
> > opengl application here:
> >
> > http://nl.linux.org/~phillips/world.tgz
> > (3D engine - see screenshots on the same page)
> >
> > The "bounce" demo is suitable for testing how steady the framerate is.
> > It's working pretty well since 2.4.73, if you leave the window in one
> > place, but scheduling gets challenging (i.e., sucks) when you drag the 3D
> > window around. How should we fix that? It's my code so I'm willing to
> > add whatever priority control is appropriate.
>
> I assume you're not asking for the scheduler to be tweaked for this. You
> want the 3d rendering to occur regardless of what is happening anywhere
> else?
I don't know what's required, this is just the next problem on my list after
sound scheduling, which as far as I'm concerned isn't particularly
interesting any more (except for the missing formal analysis) because we've
got solutions on the table.
What I want is a reasonably steady frame rate, even when the window is being
dragged. After that, being greedy, I'll want a steady rate under lots of
other challenging conditions as well. (Note there's a tweakable option in
the source to emit ms/frame.)
> If it doesn't use much cpu time but wakes lots then in it's current
> form the scheduler will happily put this equal sharing with everything at
> nice 0. X intermittently gets cpu hungry so will make this slow down at the
> moment during those bursts. Your app will go ahead of everything else at a
> priority of -3.
So why is -1 or -2 not sufficient?
> If it is cpu hungry, it will need at least -8 to get in on the act, and -13
> to be ahead of everyone (not really recommended though).
Being a 3D renderer, of course it's cpu hungry. It's also a very common type
of interactive application. As with sound, interactive 3D applications on
Linux should work by default, not be broken by default. If that means fixing
applications, so be it, let's do that to avoid going overboard with kernel
scheduling policy.
As I noted before, your patch is small, that's great. Now the thing is to
really get the goodness out of it, and avoid building in too much automagic
where it isn't appropriate.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-03 11:20 ` William Lee Irwin III
2003-07-03 11:32 ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
@ 2003-07-07 5:24 ` Zwane Mwaikambo
2003-07-07 5:47 ` William Lee Irwin III
1 sibling, 1 reply; 90+ messages in thread
From: Zwane Mwaikambo @ 2003-07-07 5:24 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Dumitru Ciobarcianu, Andrew Morton, linux-kernel, linux-mm
On Thu, 3 Jul 2003, William Lee Irwin III wrote:
> On Thu, Jul 03, 2003 at 02:17:48PM +0300, Dumitru Ciobarcianu wrote:
> > I had to mannually change the file (the patch was giving rejects), but
> > it compiles now.
>
> Great! Could you send back the diff? (or alternatively, the file
> contents if you didn't preserve the old contents) so I can send the
> proper diff upstream?
Didn't -mm get something for this?
--
function.linuxpower.ca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1 (p4-clockmod does not compile)
2003-07-07 5:24 ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
@ 2003-07-07 5:47 ` William Lee Irwin III
0 siblings, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-07 5:47 UTC (permalink / raw)
To: Zwane Mwaikambo
Cc: Dumitru Ciobarcianu, Andrew Morton, linux-kernel, linux-mm
On Thu, 3 Jul 2003, William Lee Irwin III wrote:
>> Great! Could you send back the diff? (or alternatively, the file
>> contents if you didn't preserve the old contents) so I can send the
>> proper diff upstream?
On Mon, Jul 07, 2003 at 01:24:26AM -0400, Zwane Mwaikambo wrote:
> Didn't -mm get something for this?
That's a very mysterious resend of a message that's several days old.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-06 2:14 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 2:21 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 10:00 ` Mel Gorman
2003-07-07 12:24 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Mel Gorman @ 2003-07-07 10:00 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > > What are you going to do if you have one
> > > application you want to take priority, re-nice the other 50?
> >
> > Is that effective? It might be just the trick.
>
> Point.
>
Alternatively, how about using PAM to grant the CAP_SYS_NICE capability to
known interactive users that require it. Presumably the number of users
that require it is very small (in the case of the music player, only one)
so it wouldn't be a major security issue.
There is something along these lines at http://www.pamcap.org but it
requires some patching to the kernel (only available against 2.4.18
currently) to inherit capabilities across exec and, from what I gather at
a quick glance, to allow capabilities to be set for a process group.
--
Mel Gorman
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 10:00 ` 2.5.74-mm1 Mel Gorman
@ 2003-07-07 12:24 ` Daniel Phillips
2003-07-07 13:16 ` 2.5.74-mm1 Mel Gorman
[not found] ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
0 siblings, 2 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-07 12:24 UTC (permalink / raw)
To: Mel Gorman
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Monday 07 July 2003 12:00, Mel Gorman wrote:
> On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > > > What are you going to do if you have one
> > > > application you want to take priority, re-nice the other 50?
> > >
> > > Is that effective? It might be just the trick.
> >
> > Point.
>
> Alternatively, how about using PAM to grant the CAP_SYS_NICE capability to
> known interactive users that require it. Presumably the number of users
> that require it is very small (in the case of the music player, only one)
> so it wouldn't be a major security issue.
And set up distros to grant it by default. Yes.
The problem I see is that it lets user space priorities invade the range of
priorities used by root processes. What's really needed is a range of
negative priorities available to normal users that are not normally used by
root.
In retrospect, the idea of renicing all the applications but the realtime one
doesn't work, because it doesn't take care of applications started
afterwards.
> There is something along these lines at http://www.pamcap.org but it
> requires some patching to the kernel (only available against 2.4.18
> currently) to inherit capabilities across exec and, from what I gather at
> a quick glance, to allow capabilities to be set for a process group.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 12:24 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 13:16 ` Mel Gorman
2003-07-07 14:47 ` 2.5.74-mm1 Davide Libenzi
[not found] ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
1 sibling, 1 reply; 90+ messages in thread
From: Mel Gorman @ 2003-07-07 13:16 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Mon, 7 Jul 2003, Daniel Phillips wrote:
> And set up distros to grant it by default. Yes.
>
> The problem I see is that it lets user space priorities invade the range of
> priorities used by root processes.
That is the main drawback all right but it could be addressed by having a
CAP_SYS_USERNICE capability which allows a user to renice only their own
processes to a highest priority of -5, or some other reasonable value
that wouldn't interfere with root processes. This capability would only be
for applications like music players which need to give hints to the
scheduler.
This would make it a bit Linux specific but as the pam module (currently
vapour I know) is the only piece of code that would be aware of the
distinction, it should not be much of a problem.
--
Mel Gorman
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* OOPS: 2.5.74-mm2
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
` (7 preceding siblings ...)
2003-07-05 0:16 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 13:38 ` Maciej Soltysiak
8 siblings, 0 replies; 90+ messages in thread
From: Maciej Soltysiak @ 2003-07-07 13:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Hi,
2.5.74-mm2 oopses here just after booting. I get these dumps.
Once they stoped, i pressed alt+ctl+del (noted in the dump below) and they
started again, and the computer stopeed rebooting.
Regards,
Maciej
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
CPU: 0
EIP: 0060:[schedule+143/1022] Not tainted VLI
EFLAGS: 00010097
EIP is at schedule+0x8f/0x3fe
eax: 00000001 ebx: d9bcb940 ecx: d9bcb960 edx: ffffffff
esi: 00000000 edi: c04558a0 ebp: d9b39ee0 esp: d9b39eb8
ds: 007b es: 007b ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: d9ebd980 c1403dc8 c1403dc8 00000000 40174560 d9ebd980 d9bec3c0 d9c06e6c
d9c06e00 d9b39f08 00000001 c015a837 00000000 d9bcb940 c011a7f9 d9b39f14
d9b39f14 d9ebd980 d9ebd9a0 d9bec3c0 00000000 d9bcb940 c011a7f9 d9b80f40
Call Trace:
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
<6>note: bash[462] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
[schedule+1017/1022] schedule+0x3f9/0x3fe
[generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[vgacon_cursor+236/478] vgacon_cursor+0xec/0x1de
[set_cursor+117/142] set_cursor+0x75/0x8e
[vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
[generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
[ext3_file_write+68/194] ext3_file_write+0x44/0xc2
[do_sync_write+182/227] do_sync_write+0xb6/0xe3
[mempool_free+81/177] mempool_free+0x51/0xb1
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[check_free_space+225/364] check_free_space+0xe1/0x16c
[poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
[vt_console_print+521/747] vt_console_print+0x209/0x2eb
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_acct_process+637/653] do_acct_process+0x27d/0x28d
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[acct_process+72/132] acct_process+0x48/0x84
[do_exit+135/1102] do_exit+0x87/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#2]
PREEMPT
CPU: 0
EIP: 0060:[schedule+143/1022] Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008 ebx: d9bcb940 ecx: d9bcb960 edx: ffffffff
esi: 00000000 edi: c04558a0 ebp: d9b39d88 esp: d9b39d60
ds: 007b es: 007b ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000020 00000009 d9bcb990 dbdc7b80 d9bcb9e0 00000286 dbdc7b80 dbfeea60
00000002 00000000 d9bcb940 c011e785 d9bcb940 dbcdaae0 000001ce 00000002
d9b39e84 d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
<6>note: bash[462] exited with preempt_count 4
bad: scheduling while atomic!
Call Trace:
[schedule+1017/1022] schedule+0x3f9/0x3fe
[generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
[vgacon_cursor+236/478] vgacon_cursor+0xec/0x1de
[set_cursor+117/142] set_cursor+0x75/0x8e
[vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
[generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
[ext3_file_write+68/194] ext3_file_write+0x44/0xc2
[do_sync_write+182/227] do_sync_write+0xb6/0xe3
[vgacon_scroll+386/555] vgacon_scroll+0x182/0x22b
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[check_free_space+225/364] check_free_space+0xe1/0x16c
[poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
[vt_console_print+521/747] vt_console_print+0x209/0x2eb
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_acct_process+637/653] do_acct_process+0x27d/0x28d
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[acct_process+72/132] acct_process+0x48/0x84
[do_exit+135/1102] do_exit+0x87/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[kill_fasync+48/82] kill_fasync+0x30/0x52
[pipe_release+153/203] pipe_release+0x99/0xcb
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#3]
PREEMPT
CPU: 0
EIP: 0060:[schedule+143/1022] Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008 ebx: d9bcb940 ecx: d9bcb960 edx: ffffffff
esi: 00000000 edi: c04558a0 ebp: d9b39c30 esp: d9b39c08
ds: 007b es: 007b ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000000 00000000 d9bcb990 0000000b d9bcb9e0 d9bcb940 c0132844 00000000
00000004 00000000 d9bcb940 c011e785 d9bcb940 00000000 000001ce 00000004
d9b39d2c d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[kill_fasync+48/82] kill_fasync+0x30/0x52
[pipe_release+153/203] pipe_release+0x99/0xcb
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
<6>note: bash[462] exited with preempt_count 6
bad: scheduling while atomic!
Call Trace:
[schedule+1017/1022] schedule+0x3f9/0x3fe
[generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[__down+268/290] __down+0x10c/0x122
[default_wake_function+0/46] default_wake_function+0x0/0x2e
[vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
[generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
[ext3_file_write+68/194] ext3_file_write+0x44/0xc2
[do_sync_write+182/227] do_sync_write+0xb6/0xe3
[mempool_free+81/177] mempool_free+0x51/0xb1
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[check_free_space+225/364] check_free_space+0xe1/0x16c
[poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
[vt_console_print+521/747] vt_console_print+0x209/0x2eb
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_acct_process+637/653] do_acct_process+0x27d/0x28d
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[acct_process+72/132] acct_process+0x48/0x84
[do_exit+135/1102] do_exit+0x87/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[kill_fasync+48/82] kill_fasync+0x30/0x52
[pipe_release+153/203] pipe_release+0x99/0xcb
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
I pressed alt_ctl+del here:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#4]
PREEMPT
CPU: 0
EIP: 0060:[schedule+143/1022] Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008 ebx: d9bcb940 ecx: d9bcb960 edx: ffffffff
esi: 00000000 edi: c04558a0 ebp: d9b39ad8 esp: d9b39ab0
ds: 007b es: 007b ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000000 00000000 d9bcb990 0000000b d9bcb9e0 d9bcb940 c0132844 00000000
00000006 00000000 d9bcb940 c011e785 d9bcb940 00000000 000001ce 00000006
d9b39bd4 d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[kill_fasync+48/82] kill_fasync+0x30/0x52
[pipe_release+153/203] pipe_release+0x99/0xcb
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
<6>note: bash[462] exited with preempt_count 8
bad: scheduling while atomic!
Call Trace:
[schedule+1017/1022] schedule+0x3f9/0x3fe
[generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[__down+268/290] __down+0x10c/0x122
[default_wake_function+0/46] default_wake_function+0x0/0x2e
[vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
[generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
[ext3_file_write+68/194] ext3_file_write+0x44/0xc2
[do_sync_write+182/227] do_sync_write+0xb6/0xe3
[vgacon_scroll+386/555] vgacon_scroll+0x182/0x22b
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[check_free_space+225/364] check_free_space+0xe1/0x16c
[poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
[vt_console_print+521/747] vt_console_print+0x209/0x2eb
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_acct_process+637/653] do_acct_process+0x27d/0x28d
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[acct_process+72/132] acct_process+0x48/0x84
[do_exit+135/1102] do_exit+0x87/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[acct_process+79/132] acct_process+0x4f/0x84
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
[kill_fasync+48/82] kill_fasync+0x30/0x52
[pipe_release+153/203] pipe_release+0x99/0xcb
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[schedule+143/1022] schedule+0x8f/0x3fe
[do_exit+625/1102] do_exit+0x271/0x44e
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[do_divide_error+0/250] do_divide_error+0x0/0xfa
[do_page_fault+300/1113] do_page_fault+0x12c/0x459
[__rmqueue+204/305] __rmqueue+0xcc/0x131
[buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
[do_page_fault+0/1113] do_page_fault+0x0/0x459
[error_code+45/56] error_code+0x2d/0x38
[check_version+120/216] check_version+0x78/0xd8
[schedule+143/1022] schedule+0x8f/0x3fe
[pipe_wait+123/154] pipe_wait+0x7b/0x9a
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
[pipe_read+319/573] pipe_read+0x13f/0x23d
[update_process_times+70/82] update_process_times+0x46/0x52
[vfs_read+176/281] vfs_read+0xb0/0x119
[sys_read+66/99] sys_read+0x42/0x63
[syscall_call+7/11] syscall_call+0x7/0xb
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 13:16 ` 2.5.74-mm1 Mel Gorman
@ 2003-07-07 14:47 ` Davide Libenzi
2003-07-07 15:23 ` 2.5.74-mm1 Jamie Lokier
2003-07-07 15:28 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 2 replies; 90+ messages in thread
From: Davide Libenzi @ 2003-07-07 14:47 UTC (permalink / raw)
To: Mel Gorman
Cc: Daniel Phillips, Jamie Lokier, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Mon, 7 Jul 2003, Mel Gorman wrote:
> On Mon, 7 Jul 2003, Daniel Phillips wrote:
>
> > And set up distros to grant it by default. Yes.
> >
> > The problem I see is that it lets user space priorities invade the range of
> > priorities used by root processes.
>
> That is the main drawback all right but it could be addressed by having a
> CAP_SYS_USERNICE capability which allows a user to renice only their own
> processes to a highest priority of -5, or some other reasonable value
> that wouldn't interfere with root processes. This capability would only be
> for applications like music players which need to give hints to the
> scheduler.
The scheduler has to work w/out external input, period. If it doesn't we
have to fix it and not to force the user to submit external hints.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 14:47 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 15:23 ` Jamie Lokier
2003-07-07 17:25 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 15:28 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Jamie Lokier @ 2003-07-07 15:23 UTC (permalink / raw)
To: Davide Libenzi
Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
Davide Libenzi wrote:
> The scheduler has to work w/out external input, period.
Can you justify this?
It strikes me that a music player's thread which requests a special
music-playing scheduling hint is not unreasonable, if that actually
works and scheduler heuristics do not.
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 14:47 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 15:23 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-07 15:28 ` Daniel Phillips
2003-07-07 17:58 ` 2.5.74-mm1 Davide Libenzi
1 sibling, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-07 15:28 UTC (permalink / raw)
To: Davide Libenzi, Mel Gorman
Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Monday 07 July 2003 16:47, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Mel Gorman wrote:
> > On Mon, 7 Jul 2003, Daniel Phillips wrote:
> > > And set up distros to grant it by default. Yes.
> > >
> > > The problem I see is that it lets user space priorities invade the
> > > range of priorities used by root processes.
> >
> > That is the main drawback all right but it could be addressed by having a
> > CAP_SYS_USERNICE capability which allows a user to renice only their own
> > processes to a highest priority of -5, or some other reasonable value
> > that wouldn't interfere with root processes. This capability would only
> > be for applications like music players which need to give hints to the
> > scheduler.
>
> The scheduler has to work w/out external input, period. If it doesn't we
> have to fix it and not to force the user to submit external hints.
That's not correct in this case, because the sound servicing routine is
realtime, which makes it special. Furthermore, Zinf is already trying to
provide the kernel with the hint it needs via PThreads SetPriority but
because Linux has brain damage - both in the kernel and user space imho - the
hint isn't accomplishing what it's supposed to.
As I said earlier: trying to detect automagically which threads are realtime
and which aren't is stupid. Such policy decisions don't belong in the
kernel.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
[not found] ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
@ 2003-07-07 17:15 ` Mike Galbraith
0 siblings, 0 replies; 90+ messages in thread
From: Mike Galbraith @ 2003-07-07 17:15 UTC (permalink / raw)
To: Davide Libenzi
Cc: Mel Gorman, Daniel Phillips, Jamie Lokier, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
At 07:47 AM 7/7/2003 -0700, Davide Libenzi wrote:
>On Mon, 7 Jul 2003, Mel Gorman wrote:
>
> > On Mon, 7 Jul 2003, Daniel Phillips wrote:
> >
> > > And set up distros to grant it by default. Yes.
> > >
> > > The problem I see is that it lets user space priorities invade the
> range of
> > > priorities used by root processes.
> >
> > That is the main drawback all right but it could be addressed by having a
> > CAP_SYS_USERNICE capability which allows a user to renice only their own
> > processes to a highest priority of -5, or some other reasonable value
> > that wouldn't interfere with root processes. This capability would only be
> > for applications like music players which need to give hints to the
> > scheduler.
>
>The scheduler has to work w/out external input, period. If it doesn't we
>have to fix it and not to force the user to submit external hints.
What about internal hints?
Fishing expedition:
I'm tinkering with Linus' backboost trick, and what I'd like to try is
filtering out things which are doing I/O to graphics card, sound card,
mouse, kdb... whatnot with an in_interactive_interrupt(). Before I go off
tilting at that windmill, do you (or anyone) know of any reason why that
would be either stupid or impossible?
Right now, I've got backboost max cpu consumption restricted, max priority
restricted /proc enabled and /proc tweakable, but I need to further
restrict/focus it somehow. Any ideas wrt taming/focusing the little
beastie would be appreciated. I'd really like to get it tame enough to be
reconsidered...
I like backboost for the desktop quite a bit. Take xmms for instance, fire
it up and turn on it's cpu-hog-and-a-half gl visualization. The sound
thread runs at high priority due to low cpu usage. The gl thread otoh is
down in the mud, and is instantly disturbed by background tasks who
unreasonably ;) want their fair share of cpu. With backboost, the gl
thread is boosted above background stuff where he belongs, the whole point
of interactivity being that it's not only ok to be grossly unfair about
things a human being is connecting to, it's a goodthing(tm)... worker can
stare mindlessly at glitz and listen to skip free music while his
employer's code gets moldy instead of being compiled. ;-)
Neat thing about backboost is that when you cover the gl thread, it
automagically loses boost, so when unreasonable boss walks in and you cover
it up, the compile speeds back up. The glitz thread is only interactive if
you can see it, and does in fact only receive boost when you can see
it. That's pretty cool.
-Mike
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 15:23 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-07 17:25 ` Davide Libenzi
2003-07-07 17:55 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 19:36 ` 2.5.74-mm1 Jamie Lokier
0 siblings, 2 replies; 90+ messages in thread
From: Davide Libenzi @ 2003-07-07 17:25 UTC (permalink / raw)
To: Jamie Lokier
Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Mon, 7 Jul 2003, Jamie Lokier wrote:
> Davide Libenzi wrote:
> > The scheduler has to work w/out external input, period.
>
> Can you justify this?
>
> It strikes me that a music player's thread which requests a special
> music-playing scheduling hint is not unreasonable, if that actually
> works and scheduler heuristics do not.
Jamie, looking at those reports it seems it is not only a sound players
problem. It is fine that an application that has strict timing issues
hints the scheduler. The *application* has to hint the scheduler, not the
user. If reports about UI interactivity are true, this means that there's
something wrong in the current scheduler though. Besides the player issue.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 17:25 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 17:55 ` Daniel Phillips
2003-07-07 18:36 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 19:36 ` 2.5.74-mm1 Jamie Lokier
1 sibling, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-07 17:55 UTC (permalink / raw)
To: Davide Libenzi, Jamie Lokier
Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Jamie Lokier wrote:
> > Davide Libenzi wrote:
> > > The scheduler has to work w/out external input, period.
> >
> > Can you justify this?
> >
> > It strikes me that a music player's thread which requests a special
> > music-playing scheduling hint is not unreasonable, if that actually
> > works and scheduler heuristics do not.
>
> Jamie, looking at those reports it seems it is not only a sound players
> problem.
You still seem to be having trouble with the idea that the sound servicing
thread is a realtime process, and thus fundamentally different from other
kinds of processes. Could you please explain why you disagree with this?
> The *application* has to hint the scheduler, not the user.
Partly true, in that users should be able to supply the hint in some way, they
desire. However in this case - Zinf - the point is moot, because Zinf is
trying hard to give the hint, but it fails because of above-mentioned
braindamage.
> If reports about UI interactivity are true, this means that there's
> something wrong in the current scheduler though. Besides the player issue.
The current scheduler, complete with Con's tweaks, is working very well for me
in combination with "nice -something". The remaining issue there is pure
policy. In that regard, I'm trying to find the most appropriate way of
fixing up user space so that Zinf's SetPriority actually achieves its
intended effect. Running all logins at some setable non-negative default
priority is the best idea I've seen so far in that regard, and soon my system
will be doing just that. I'll let you know if anything explodes ;-)
If there's a remaining fundamental flaw in the kernel scheduler, it would be
the lower-priority process starvation question, which holds the promise of
plenty of future lkml navel gaz^W^Wdiscussion indeed.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 15:28 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 17:58 ` Davide Libenzi
0 siblings, 0 replies; 90+ messages in thread
From: Davide Libenzi @ 2003-07-07 17:58 UTC (permalink / raw)
To: Daniel Phillips
Cc: Mel Gorman, Jamie Lokier, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Mon, 7 Jul 2003, Daniel Phillips wrote:
> That's not correct in this case, because the sound servicing routine is
> realtime, which makes it special. Furthermore, Zinf is already trying to
> provide the kernel with the hint it needs via PThreads SetPriority but
> because Linux has brain damage - both in the kernel and user space imho - the
> hint isn't accomplishing what it's supposed to.
>
> As I said earlier: trying to detect automagically which threads are realtime
> and which aren't is stupid. Such policy decisions don't belong in the
> kernel.
Having hacked a little bit with vsound I can say that many sound players
do not use at 100% the buffering the sound card/kernel is able to provide
and they still use 4-8Kb feeding chunks. That require very short timings
to not lose the time.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 17:55 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 18:36 ` Davide Libenzi
2003-07-07 19:07 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 19:39 ` 2.5.74-mm1 Jamie Lokier
0 siblings, 2 replies; 90+ messages in thread
From: Davide Libenzi @ 2003-07-07 18:36 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jamie Lokier, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Mon, 7 Jul 2003, Daniel Phillips wrote:
> On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> >
> > Jamie, looking at those reports it seems it is not only a sound players
> > problem.
>
> You still seem to be having trouble with the idea that the sound servicing
> thread is a realtime process, and thus fundamentally different from other
> kinds of processes. Could you please explain why you disagree with this?
I'm just trying to figure out why :
1) RealPlayer does not skip on my 2.4.20
2) RealPlayer does not skip on my office XP
3) MediaPlayer does not skip on my office XP
Maybe it is more of an application problem.
> > The *application* has to hint the scheduler, not the user.
>
> Partly true, in that users should be able to supply the hint in some way, they
> desire. However in this case - Zinf - the point is moot, because Zinf is
> trying hard to give the hint, but it fails because of above-mentioned
> braindamage.
Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
Feeding the sound card with 4Kb writes will make you skip after about 50ms
CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
makes it able to sustain up to 200ms of blackout.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 18:36 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 19:07 ` Daniel Phillips
2003-07-07 19:39 ` 2.5.74-mm1 Jamie Lokier
1 sibling, 0 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-07 19:07 UTC (permalink / raw)
To: Davide Libenzi
Cc: Jamie Lokier, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Monday 07 July 2003 20:36, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Daniel Phillips wrote:
> > On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> > > Jamie, looking at those reports it seems it is not only a sound players
> > > problem.
> >
> > You still seem to be having trouble with the idea that the sound
> > servicing thread is a realtime process, and thus fundamentally different
> > from other kinds of processes. Could you please explain why you disagree
> > with this?
>
> I'm just trying to figure out why :
>
> 1) RealPlayer does not skip on my 2.4.20
^^^^^^
We're talking about 2.5.
> 2) RealPlayer does not skip on my office XP
> 3) MediaPlayer does not skip on my office XP
>
> Maybe it is more of an application problem.
Partly. We've been through that in pretty good detail. There are
combinations of hardware and kernel versions that happen to be pretty good at
running sound, that doesn't mean the problem is dealt with so that corner
cases don't come up. A 99% solution is not good enough, that still will
leave 10,000's of Linux users with poor sound performance.
Zinf does things correctly: it has a big buffer and it tries to set an
elevated priority for its sound servicing thread. With 2.5, that isn't
enough, and Con's tweaking isn't enough. And that's not wrong, because the
kernel *should not* try to identify realtime threads automagically.
Zinf could go further and try to set a posix realtime scheduling mode, but
that attempt would be blocked by the root requirement for realtime
scheduling, which is ihmo due to braindamage in the definition of the posix
realtime scheduling modes. This last we *can* fix in the kernel, by creating
a new realtime scheduling mode that is sane enough to be used by normal
users. Then sound applications would need to be changed to use it, which
really is no big deal.
In the meantime, a combination of Con's priority tweaks and user-initiated
nice works well.
> > > The *application* has to hint the scheduler, not the user.
> >
> > Partly true, in that users should be able to supply the hint in some way,
> > they desire. However in this case - Zinf - the point is moot, because
> > Zinf is trying hard to give the hint, but it fails because of
> > above-mentioned braindamage.
>
> Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> Feeding the sound card with 4Kb writes will make you skip after about 50ms
> CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> makes it able to sustain up to 200ms of blackout.
That's just fiddling, it doesn't deal with the basic problem. Anyway, big
buffers have their own annoyances. Have you tried the graphic equalizer in
xmms lately? A one second lag on slider adjustment is not nice.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 17:25 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 17:55 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 19:36 ` Jamie Lokier
2003-07-09 22:17 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Jamie Lokier @ 2003-07-07 19:36 UTC (permalink / raw)
To: Davide Libenzi
Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
Davide Libenzi wrote:
> The *application* has to hint the scheduler, not the user.
Agreed.
(I think the user/PAM idea came up for the same sort of reason that
only console users are able to open /dev/cdrom: asking for extra
resource (in this case low latency is a resource) might be something
you'd restrict to console users. But that is a very separate question
from how do we get low latency to work at all!)
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 18:36 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 19:07 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 19:39 ` Jamie Lokier
1 sibling, 0 replies; 90+ messages in thread
From: Jamie Lokier @ 2003-07-07 19:39 UTC (permalink / raw)
To: Davide Libenzi
Cc: Daniel Phillips, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
Davide Libenzi wrote:
> Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> Feeding the sound card with 4Kb writes will make you skip after about 50ms
> CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> makes it able to sustain up to 200ms of blackout.
Large buffers are fine for streaming, provided you aren't sliding the
volume or graphic equaliser. I find xmms annoying in this regard: I
adjust the eq and wait some absurd length of time (fully tenths of a
second :) to hear the feedback.
Large buffers are useless for games or telephony.
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-07 19:36 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-09 22:17 ` Daniel Phillips
2003-07-09 22:24 ` 2.5.74-mm1 Jamie Lokier
0 siblings, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-09 22:17 UTC (permalink / raw)
To: Jamie Lokier, Davide Libenzi
Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Monday 07 July 2003 21:36, Jamie Lokier wrote:
> Davide Libenzi wrote:
> > The *application* has to hint the scheduler, not the user.
>
> Agreed.
>
> (I think the user/PAM idea came up for the same sort of reason that
> only console users are able to open /dev/cdrom: asking for extra
> resource (in this case low latency is a resource) might be something
> you'd restrict to console users.
I frequently run Zinf over ssh, to a machine that's connected to speakers.
> But that is a very separate question from how do we get low latency to work
> at all!)
We've got something better than we've had before, even though it doesn't go as
far as making true realtime processing available to normal users.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 22:17 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-09 22:24 ` Jamie Lokier
2003-07-09 22:29 ` 2.5.74-mm1 Davide Libenzi
2003-07-09 22:59 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 2 replies; 90+ messages in thread
From: Jamie Lokier @ 2003-07-09 22:24 UTC (permalink / raw)
To: Daniel Phillips
Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
Daniel Phillips wrote:
> > (I think the user/PAM idea came up for the same sort of reason that
> > only console users are able to open /dev/cdrom: asking for extra
> > resource (in this case low latency is a resource) might be something
> > you'd restrict to console users.
>
> I frequently run Zinf over ssh, to a machine that's connected to speakers.
I do similar things. I also read /dev/cdrom over ssh, which is not
permitted by the default security policy. I.e. it's a userspace
policy issue.
> We've got something better than we've had before, even though it doesn't go as
> far as making true realtime processing available to normal users.
Indeed. But maybe true (bounded CPU) realtime, reliable, would more
accurately reflect what the user actually wants for some apps?
Just a thought,
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 22:24 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-09 22:29 ` Davide Libenzi
2003-07-09 23:15 ` 2.5.74-mm1 Daniel Phillips
2003-07-09 22:59 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Davide Libenzi @ 2003-07-09 22:29 UTC (permalink / raw)
To: Jamie Lokier
Cc: Daniel Phillips, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Wed, 9 Jul 2003, Jamie Lokier wrote:
> Indeed. But maybe true (bounded CPU) realtime, reliable, would more
> accurately reflect what the user actually wants for some apps?
Hopefully I'll have a couple of hours free to code and test the
SCHED_SOFTRR idea ;) It's hard to push for a new POSIX definition though :)
Looking at recent posts it seems that this is not the only problem though.
It seems interactivity lowered in the latest versions of the scheduler.
The good news is that Ingo is back on Earth and he'll fix it :)
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 22:24 ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:29 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-09 22:59 ` Daniel Phillips
2003-07-10 2:01 ` 2.5.74-mm1 Peter Chubb
1 sibling, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-09 22:59 UTC (permalink / raw)
To: Jamie Lokier
Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Thursday 10 July 2003 00:24, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > We've got something better than we've had before, even though it doesn't
> > go as far as making true realtime processing available to normal users.
>
> Indeed. But maybe true (bounded CPU) realtime, reliable, would more
> accurately reflect what the user actually wants for some apps?
No doubt about it. Other OSes have it:
http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?realtime+5
Hopefully in the next cycle, we will too.
I like your idea of allowing normal users to set SCHED_RR, but automatically
placing some bound on cpu usage. It's guaranteed not to break any existing
programs.
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 22:29 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-09 23:15 ` Daniel Phillips
2003-07-09 23:19 ` 2.5.74-mm1 Jamie Lokier
0 siblings, 1 reply; 90+ messages in thread
From: Daniel Phillips @ 2003-07-09 23:15 UTC (permalink / raw)
To: Davide Libenzi, Jamie Lokier
Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Thursday 10 July 2003 00:29, Davide Libenzi wrote:
> On Wed, 9 Jul 2003, Jamie Lokier wrote:
> > Indeed. But maybe true (bounded CPU) realtime, reliable, would more
> > accurately reflect what the user actually wants for some apps?
>
> Hopefully I'll have a couple of hours free to code and test the
> SCHED_SOFTRR idea ;) It's hard to push for a new POSIX definition though :)
Oops, sorry for attributing that to Jamie instead of you :-/
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 23:15 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-09 23:19 ` Jamie Lokier
0 siblings, 0 replies; 90+ messages in thread
From: Jamie Lokier @ 2003-07-09 23:19 UTC (permalink / raw)
To: Daniel Phillips
Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
Daniel Phillips wrote:
> Oops, sorry for attributing that to Jamie instead of you :-/
They say great minds think alike ;)
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-09 22:59 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-10 2:01 ` Peter Chubb
2003-07-11 1:04 ` 2.5.74-mm1 Daniel Phillips
0 siblings, 1 reply; 90+ messages in thread
From: Peter Chubb @ 2003-07-10 2:01 UTC (permalink / raw)
To: Daniel Phillips
Cc: Jamie Lokier, Davide Libenzi, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
>>>>> "Daniel" == Daniel Phillips <phillips@arcor.de> writes:
Daniel> I like your idea of allowing normal users to set SCHED_RR, but
Daniel> automatically placing some bound on cpu usage. It's
Daniel> guaranteed not to break any existing programs.
I suspect that what's really wanted here is not SCHED_RR but
guaranteed rate-of-forward progress. A dynamic-window-constrained
scheduler (that guarantees not that you'll run until you sleep, but
that in any (settable) time period you'll get the opportunity to run
for at least (a smaller settable period)) is closer to what's wanted.
See http://www.cs.bu.edu/fac/richwest/dwcs.html
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all slightly different.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-10 2:01 ` 2.5.74-mm1 Peter Chubb
@ 2003-07-11 1:04 ` Daniel Phillips
2003-07-11 1:08 ` 2.5.74-mm1 William Lee Irwin III
2003-07-11 5:44 ` 2.5.74-mm1 Davide Libenzi
0 siblings, 2 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-11 1:04 UTC (permalink / raw)
To: Peter Chubb
Cc: Jamie Lokier, Davide Libenzi, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Thursday 10 July 2003 04:01, Peter Chubb wrote:
> I suspect that what's really wanted here is not SCHED_RR but
> guaranteed rate-of-forward progress.
I suspect you are right. I'd also like to note that this is ground so
thoroughly trodden that the grass is flat. Realtime schedulers are a well
researched topic, it's just too bad that committees don't design them as well
as engineers would.
Thinking strictly about the needs of sound processing, what's needed is a
guarantee of so much cpu time each time the timer fires, and a user limit to
prevent cpu hogging. It's worth pondering the difference between that and
rate-of-forward-progress. I suspect some simple improvements to the current
scheduler can be made to do the job, and at the same time, avoid the
priorty-based starvation issue that seems to have been practically mandated
by POSIX.
> A dynamic-window-constrained
> scheduler (that guarantees not that you'll run until you sleep, but
> that in any (settable) time period you'll get the opportunity to run
> for at least (a smaller settable period)) is closer to what's wanted.
It's possible that may be equivalent to what I said :-)
> See http://www.cs.bu.edu/fac/richwest/dwcs.html
This is an interesting link. One of the design rules has to be that O(1)
performance is never degraded, at least when there are no realtime processes.
Also, I want to be clear that I'm not suggesting this sort of thing has
anything to do with the current cycle, unless tweaking of the incumbent
sheduler fails for some reason, which it seems unlikely to do.
Regards,
Daniel
>
> --
> Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
> You are lost in a maze of BitKeeper repositories, all slightly different.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-11 1:04 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-11 1:08 ` William Lee Irwin III
2003-07-11 5:44 ` 2.5.74-mm1 Davide Libenzi
1 sibling, 0 replies; 90+ messages in thread
From: William Lee Irwin III @ 2003-07-11 1:08 UTC (permalink / raw)
To: Daniel Phillips
Cc: Peter Chubb, Jamie Lokier, Davide Libenzi, Mel Gorman,
Andrew Morton, Linux Kernel Mailing List,
Linux Memory Management List
On Fri, Jul 11, 2003 at 03:04:11AM +0200, Daniel Phillips wrote:
> Thinking strictly about the needs of sound processing, what's needed is a
> guarantee of so much cpu time each time the timer fires, and a user limit to
> prevent cpu hogging. It's worth pondering the difference between that and
> rate-of-forward-progress. I suspect some simple improvements to the current
> scheduler can be made to do the job, and at the same time, avoid the
> priorty-based starvation issue that seems to have been practically mandated
> by POSIX.
Such scheduling policies are called "isochronous".
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-11 1:04 ` 2.5.74-mm1 Daniel Phillips
2003-07-11 1:08 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-11 5:44 ` Davide Libenzi
2003-07-11 8:07 ` 2.5.74-mm1 Daniel Phillips
1 sibling, 1 reply; 90+ messages in thread
From: Davide Libenzi @ 2003-07-11 5:44 UTC (permalink / raw)
To: Daniel Phillips
Cc: Peter Chubb, Jamie Lokier, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Fri, 11 Jul 2003, Daniel Phillips wrote:
> I suspect you are right. I'd also like to note that this is ground so
> thoroughly trodden that the grass is flat. Realtime schedulers are a well
> researched topic, it's just too bad that committees don't design them as well
> as engineers would.
>
> Thinking strictly about the needs of sound processing, what's needed is a
> guarantee of so much cpu time each time the timer fires, and a user limit to
> prevent cpu hogging. It's worth pondering the difference between that and
> rate-of-forward-progress. I suspect some simple improvements to the current
> scheduler can be made to do the job, and at the same time, avoid the
> priorty-based starvation issue that seems to have been practically mandated
> by POSIX.
I've been finally able to make my sound card to sing with 2.5 and I was
able to sh*t load my machine running RealPlay with the SOFTRR path :
http://www.xmailserver.org/linux-patches/softrr.html
I was not able to get a single skip. For many kind of applications it is
not strong real time that is needed. For example, in case on those
multimedia pps, I saw that they can live pretty happy with 10-20ms
latencies. The problem is that w/out living in the realtime priority even,
they can be sucked in by interactive tasks running they loong timeslice
multiple times. Plus-latencies of 100-150ms are very easy to get. Even if
the average latency, like graphs show, is very close to the expected one.
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.5.74-mm1
2003-07-11 5:44 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-11 8:07 ` Daniel Phillips
0 siblings, 0 replies; 90+ messages in thread
From: Daniel Phillips @ 2003-07-11 8:07 UTC (permalink / raw)
To: Davide Libenzi
Cc: Peter Chubb, Jamie Lokier, Mel Gorman, Andrew Morton,
Linux Kernel Mailing List, Linux Memory Management List
On Friday 11 July 2003 07:44, Davide Libenzi wrote:
> http://www.xmailserver.org/linux-patches/softrr.html
:-)
Regards,
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2003-07-11 8:07 UTC | newest]
Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-03 9:37 2.5.74-mm1 Andrew Morton
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
2003-07-03 11:07 ` William Lee Irwin III
2003-07-03 11:17 ` Dumitru Ciobarcianu
2003-07-03 11:20 ` William Lee Irwin III
2003-07-03 11:32 ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
2003-07-07 5:24 ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
2003-07-07 5:47 ` William Lee Irwin III
2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
2003-07-03 13:30 ` Con Kolivas
2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
2003-07-03 20:48 ` 2.5.74-mm1 William Lee Irwin III
2003-07-04 8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
2003-07-04 8:53 ` William Lee Irwin III
2003-07-04 9:35 ` William Lee Irwin III
2003-07-04 9:50 ` William Lee Irwin III
2003-07-04 10:02 ` William Lee Irwin III
2003-07-04 10:07 ` William Lee Irwin III
2003-07-04 11:12 ` Helge Hafting
2003-07-04 11:10 ` William Lee Irwin III
2003-07-04 15:41 ` Martin J. Bligh
2003-07-04 15:47 ` Zwane Mwaikambo
2003-07-04 16:18 ` Martin J. Bligh
2003-07-04 16:16 ` Zwane Mwaikambo
2003-07-04 18:31 ` William Lee Irwin III
2003-07-04 19:20 ` Martin J. Bligh
2003-07-04 19:31 ` William Lee Irwin III
2003-07-04 19:53 ` Martin J. Bligh
2003-07-04 20:17 ` William Lee Irwin III
2003-07-04 18:32 ` William Lee Irwin III
2003-07-04 18:36 ` William Lee Irwin III
2003-07-04 18:29 ` William Lee Irwin III
2003-07-04 18:26 ` William Lee Irwin III
2003-07-04 19:38 ` Martin J. Bligh
2003-07-04 20:07 ` William Lee Irwin III
2003-07-04 20:37 ` Martin J. Bligh
2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 1:15 ` 2.5.74-mm1 Andrew Morton
2003-07-05 5:21 ` 2.5.74-mm1 Anton Blanchard
2003-07-05 11:18 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 11:46 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 10:44 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 18:43 ` 2.5.74-mm1 Andrew Morton
2003-07-05 21:17 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 21:27 ` 2.5.74-mm1 Andrew Morton
2003-07-05 22:03 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 0:16 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 15:28 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 16:01 ` 2.5.74-mm1 Con Kolivas
2003-07-05 17:47 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 3:41 ` 2.5.74-mm1 Con Kolivas
2003-07-06 18:50 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 19:14 ` 2.5.74-mm1 Andrew Morton
2003-07-05 21:09 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 21:44 ` 2.5.74-mm1 Jamie Lokier
2003-07-05 22:10 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 1:28 ` 2.5.74-mm1 Jamie Lokier
2003-07-06 2:14 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 2:21 ` 2.5.74-mm1 Davide Libenzi
2003-07-06 13:54 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 10:00 ` 2.5.74-mm1 Mel Gorman
2003-07-07 12:24 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 13:16 ` 2.5.74-mm1 Mel Gorman
2003-07-07 14:47 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 15:23 ` 2.5.74-mm1 Jamie Lokier
2003-07-07 17:25 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 17:55 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 18:36 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 19:07 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 19:39 ` 2.5.74-mm1 Jamie Lokier
2003-07-07 19:36 ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:17 ` 2.5.74-mm1 Daniel Phillips
2003-07-09 22:24 ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:29 ` 2.5.74-mm1 Davide Libenzi
2003-07-09 23:15 ` 2.5.74-mm1 Daniel Phillips
2003-07-09 23:19 ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:59 ` 2.5.74-mm1 Daniel Phillips
2003-07-10 2:01 ` 2.5.74-mm1 Peter Chubb
2003-07-11 1:04 ` 2.5.74-mm1 Daniel Phillips
2003-07-11 1:08 ` 2.5.74-mm1 William Lee Irwin III
2003-07-11 5:44 ` 2.5.74-mm1 Davide Libenzi
2003-07-11 8:07 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 15:28 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 17:58 ` 2.5.74-mm1 Davide Libenzi
[not found] ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
2003-07-07 17:15 ` 2.5.74-mm1 Mike Galbraith
2003-07-06 0:10 ` 2.5.74-mm1 Daniel Phillips
2003-07-06 0:10 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox