kernel.git/arch/ia64, branch linux-2.6.19.y

[PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code

2007-01-10T19:05:19Z

Fernando Lopez-Lezcano reported frequent scheduling latencies and audio xruns starting at the 2.6.18-rt kernel, and those problems persisted all until current -rt kernels. The latencies were serious and unjustified by system load, often in the milliseconds range. After a patient and heroic multi-month effort of Fernando, where he tested dozens of kernels, tried various configs, boot options, test-patches of mine and provided latency traces of those incidents, the following 'smoking gun' trace was captured by him: _------=> CPU# / _-----=> irqs-off | / _----=> need-resched || / _---=> hardirq/softirq ||| / _--=> preempt-depth |||| / ||||| delay cmd pid ||||| time | caller \ / ||||| \ | / IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (try_to_wake_up) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup <<...>-5856> (37 0) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (c01262ba 0 0) IRQ_19-1479 1D..1 0us : resched_task (try_to_wake_up) IRQ_19-1479 1D..1 0us : __spin_unlock_irqrestore (try_to_wake_up) ... -0 1...1 11us!: default_idle (cpu_idle) ... -0 0Dn.1 602us : smp_apic_timer_interrupt (c0103baf 1 0) ... <...>-5856 0D..2 618us : __switch_to (__schedule) <...>-5856 0D..2 618us : __schedule <-0> (20 162) <...>-5856 0D..2 619us : __spin_unlock_irq (__schedule) <...>-5856 0...1 619us : trace_stop_sched_switched (__schedule) <...>-5856 0D..1 619us : trace_stop_sched_switched <<...>-5856> (37 0) what is visible in this trace is that CPU#1 ran try_to_wake_up() for PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task() for CPU#0. But it decided to not send an IPI that no CPU - due to TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set, and only rescheduled to PID:5856 upon the next lapic timer IRQ. The result was a 600+ usecs latency and a missed wakeup! the bug turned out to be an idle-wakeup bug introduced into the mainline kernel this summer via an optimization in the x86_64 tree: commit 495ab9c045e1b0e5c82951b762257fe1c9d81564 Author: Andi Kleen Date: Mon Jun 26 13:59:11 2006 +0200 [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status During some profiling I noticed that default_idle causes a lot of memory traffic. I think that is caused by the atomic operations to clear/set the polling flag in thread_info. There is actually no reason to make this atomic - only the idle thread does it to itself, other CPUs only read it. So I moved it into ti->status. the problem is this type of change: if (!hlt_counter && boot_cpu_data.hlt_works_ok) { - clear_thread_flag(TIF_POLLING_NRFLAG); + current_thread_info()->status &= ~TS_POLLING; smp_mb__after_clear_bit(); while (!need_resched()) { local_irq_disable(); this changes clear_thread_flag() to an explicit clearing of TS_POLLING. clear_thread_flag() is defined as: clear_bit(flag, &ti->flags); and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms: static inline void clear_bit(int nr, volatile unsigned long * addr) { __asm__ __volatile__( LOCK_PREFIX "btrl %1,%0" hence smp_mb__after_clear_bit() is defined as a simple compile barrier: #define smp_mb__after_clear_bit() barrier() but the explicit TS_POLLING clearing introduced by the patch: + current_thread_info()->status &= ~TS_POLLING; is not an atomic op! So the clearing of the TS_POLLING bit is freely reorderable with the reading of the NEED_RESCHED bit - and both now reside in different memory addresses. CPU idle wakeup very much depends on ordered memory ops, the clearing of the TS_POLLING flag must always be done before we test need_resched() and hit the idle instruction(s). [Symmetrically, the wakeup code needs to set NEED_RESCHED before it tests the TS_POLLING flag, so memory ordering is paramount.] Fernando's dual-core Athlon64 system has a sufficiently advanced memory ordering model so that it triggered this scenario very often. ( And it also turned out that the reason why these latencies never triggered on my testsystems is that i routinely use idle=poll, which was the only idle variant not affected by this bug. ) The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to act as an absolute barrier between the TS_POLLING write and the NEED_RESCHED read. This affects almost all idling methods (default, ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64. Signed-off-by: Ingo Molnar Tested-by: Fernando Lopez-Lezcano [chrisw: backport to 2.6.19.1] Signed-off-by: Chris Wright

[IA64] a fix towards allmodconfig build

2006-11-16T19:25:12Z

The HP_SIMSCSI driver can't be built as a module (unhealthy dependencies on things that shouldn't really be exported). Signed-off-by: Andrew Morton Signed-off-by: Tony Luck

[IA64] use generic_handle_irq()

2006-11-16T17:38:35Z

Use generic_handle_irq() to handle mixed-type irq handling. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Tony Luck

[IA64] typename -> name conversion

2006-11-16T17:38:02Z

convert irq chip typename -> name. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Tony Luck

[IA64] irqs: use `name' not `typename'

2006-11-16T17:37:45Z

`typename' is going away and is usually uninitialised anwyay. Signed-off-by: Andrew Morton Signed-off-by: Tony Luck

[IA64] bte_unaligned_copy() transfers one extra cache line.

2006-11-15T18:12:15Z

When called to do a transfer that has a start offset within the cache line which is uneven between source and destination and a length which terminates the source of the copy exactly on a cache line, one extra line gets copied into a temporary buffer. This is normally not an issue since the buffer is a kernel buffer and only the requested information gets copied into the user buffer. The problem arises when the source ends at the very last physical page of memory. That last cache line does not exist and results in the SHUB chip raising an MCA. Signed-off-by: Robin Holt Signed-off-by: Dean Nelson Signed-off-by: Tony Luck

[PATCH] hugetlb: prepare_hugepage_range check offset too

2006-11-14T17:09:27Z

(David:) If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example, because the given file offset is not hugepage aligned - then do_mmap_pgoff will go to the unmap_and_free_vma backout path. But at this stage the vma hasn't been marked as hugepage, and the backout path will call unmap_region() on it. That will eventually call down to the non-hugepage version of unmap_page_range(). On ppc64, at least, that will cause serious problems if there are any existing hugepage pagetable entries in the vicinity - for example if there are any other hugepage mappings under the same PUD. unmap_page_range() will trigger a bad_pud() on the hugepage pud entries. I suspect this will also cause bad problems on ia64, though I don't have a machine to test it on. (Hugh:) prepare_hugepage_range() should check file offset alignment when it checks virtual address and length, to stop MAP_FIXED with a bad huge offset from unmapping before it fails further down. PowerPC should apply the same prepare_hugepage_range alignment checks as ia64 and all the others do. Then none of the alignment checks in hugetlbfs_file_mmap are required (nor is the check for too small a mapping); but even so, move up setting of VM_HUGETLB and add a comment to warn of what David Gibson discovered - if hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region when unwinding from error will go the non-huge way, which may cause bad behaviour on architectures (powerpc and ia64) which segregate their huge mappings into a separate region of the address space. Signed-off-by: Hugh Dickins Cc: "Luck, Tony" Cc: "David S. Miller" Acked-by: Adam Litke Acked-by: David Gibson Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] mspec driver build fix

2006-11-13T15:40:42Z

Fix MSPEC driver to build for non SN2 enabled configs as the driver should work in cached and uncached modes (no fetchop) on these systems. In addition make MSPEC select IA64_UNCACHED_ALLOCATOR, which is required for it and move it to arch/ia64/Kconfig to avoid warnings on non ia64 architectures running allmodconfig. Once the Kconfig code is fixed, we can move it back. Signed-off-by: Jes Sorensen Cc: Fernando Luis Vzquez Cao Cc: "Luck, Tony" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ia64: select ACPI_NUMA if ACPI

2006-11-09T02:29:24Z

When ACPI && NUMA, pxm_to_node is used and it exists in drivers/acpi/numa.c Tony said: The patch makes sense ... if you pick both of "ACPI" and "NUMA", then you need (and should automatically be given) ACPI_NUMA too. The only open question is whether there is a better way of getting there. Perhaps with less configuration options in the first place? We are heading towards a future where so many systems will be NUMA that there would seem to be little benefit in keeping ACPI_NUMA separate from ACPI ... but perhaps we aren't quite there yet. Signed-off-by: KAMEZAWA Hiroyuki Cc: Len Brown Acked-by: "Luck, Tony" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'release' of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6

2006-11-01T01:03:50Z

* 'release' of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Correct definition of handle_IPI [IA64] move SAL_CACHE_FLUSH check later in boot [IA64] MCA recovery: Montecito support [IA64] cpu-hotplug: Fixing confliction between CPU hot-add and IPI [IA64] don't double >> PAGE_SHIFT pointer for /dev/kmem access