pm24.git/arch/alpha, branch v2.6.15

[PATCH] arch/alpha/kernel/machvec_impl.h: C99 struct initializer

2005-12-15T18:04:31Z

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[PATCH] sched: resched and cpu_idle rework

2005-11-09T15:56:33Z

Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce confusion, and make their semantics rigid. Improves efficiency of resched_task and some cpu_idle routines. * In resched_task: - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held, and as we hold it during resched_task, then there is no need for an atomic test and set there. The only other time this should be set is when the task's quantum expires, in the timer interrupt - this is protected against because the rq lock is irq-safe. - If TIF_NEED_RESCHED is set, then we don't need to do anything. It won't get unset until the task get's schedule()d off. - If we are running on the same CPU as the task we resched, then set TIF_NEED_RESCHED and no further action is required. - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set after TIF_NEED_RESCHED has been set, then we need to send an IPI. Using these rules, we are able to remove the test and set operation in resched_task, and make clear the previously vague semantics of POLLING_NRFLAG. * In idle routines: - Enter cpu_idle with preempt disabled. When the need_resched() condition becomes true, explicitly call schedule(). This makes things a bit clearer (IMO), but haven't updated all architectures yet. - Many do a test and clear of TIF_NEED_RESCHED for some reason. According to the resched_task rules, this isn't needed (and actually breaks the assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock held). So remove that. Generally one less locked memory op when switching to the idle thread. - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner most polling idle loops. The above resched_task semantics allow it to be set until before the last time need_resched() is checked before going into a halt requiring interrupt wakeup. Many idle routines simply never enter such a halt, and so POLLING_NRFLAG can be always left set, completely eliminating resched IPIs when rescheduling the idle task. POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs. Signed-off-by: Nick Piggin Cc: Ingo Molnar Cc: Con Kolivas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] jiffies_64 cleanup

2005-10-31T01:37:25Z

Define jiffies_64 in kernel/timer.c rather than having 24 duplicated defines in each architecture. Signed-off-by: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] memory hotplug locking: node_size_lock

2005-10-30T04:40:44Z

pgdat->node_size_lock is basically only neeeded in one place in the normal code: show_mem(), which is the arch-specific sysrq-m printing function. Strictly speaking, the architectures not doing memory hotplug do no need this locking in show_mem(). However, they are all included for completeness. This should also make any future consolidation of all of the implementations a little more straightforward. This lock is also held in the sparsemem code during a memory removal, as sections are invalidated. This is the place there pfn_valid() is made false for a memory area that's being removed. The lock is only required when doing pfn_valid() operations on memory which the user does not already have a reference on the page, such as in show_mem(). Signed-off-by: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] mm: init_mm without ptlock

2005-10-30T04:40:40Z

First step in pushing down the page_table_lock. init_mm.page_table_lock has been used throughout the architectures (usually for ioremap): not to serialize kernel address space allocation (that's usually vmlist_lock), but because pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it. Reverse that: don't lock or unlock init_mm.page_table_lock in any of the architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take and drop it when allocating a new one, to check lest a racing task already did. Similarly no page_table_lock in vmalloc's map_vm_area. Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle user mms, which are converted only by a later patch, for now they have to lock differently according to whether or not it's init_mm. If sources get muddled, there's a danger that an arch source taking init_mm.page_table_lock will be mixed with common source also taking it (or neither take it). So break the rules and make another change, which should break the build for such a mismatch: remove the redundant mm arg from pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13). Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64 used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64 map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free took page_table_lock for no good reason. Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] gfp_t: remaining bits of arch/*

2005-10-28T15:16:51Z

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[PATCH] gfp_t: dma-mapping (alpha)

2005-10-28T15:16:48Z

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[PATCH] alpha: fix kernel alignment traps

2005-10-02T21:32:49Z

Pass in the pointer to the on-stack registers rather than using them directly as the arguments. Ivan noticed that I missed a spot when purging the registers as first stack parameter idiom. Signed-off-by: Linus Torvalds

[PATCH] alpha: fix kernel panic during SysRq-b

2005-09-23T05:17:34Z

acquire_console_sem() does BUG() in interrupt context now, as in the case of SysRq-b. Cc: Richard Henderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Alpha: ISA IRQs fixup for dp264

2005-09-19T17:00:59Z

Basically, this extends original dp264 fixup to all dp264 variations. Here is one minor change: mask out bits 4-7 of a value assigned by SRM, because - newer consoles report ISA IRQs with offset 0xe0; - even if console IRQ value is bogus, we'll have a value < 16 so it should be harmless as it won't clash with native IRQs. Particularly this fixes USB interrupt problem on xp1000 and es40. Signed-off-by: Ivan Kokshaysky Acked-by: Richard Henderson Signed-off-by: Linus Torvalds