aboutsummaryrefslogtreecommitdiff
path: root/arch/ia64
AgeCommit message (Collapse)Author
2005-11-07[PATCH] Kprobes: preempt_disable/enable() simplificationAnanth N Mavinakayanahalli
Reorganize the preempt_disable/enable calls to eliminate the extra preempt depth. Changes based on Paul McKenney's review suggestions for the kprobes RCU changeset. Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] Kprobes: Use RCU for (un)register synchronization - arch changesAnanth N Mavinakayanahalli
Changes to the arch kprobes infrastructure to take advantage of the locking changes introduced by usage of RCU for synchronization. All handlers are now run without any locks held, so they have to be re-entrant or provide their own synchronization. Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] Kprobes: Track kprobe on a per_cpu basis - ia64 changesAnanth N Mavinakayanahalli
IA64 changes to track kprobe execution on a per-cpu basis. We now track the kprobe state machine independently on each cpu using an arch specific kprobe control block. Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] Kprobes: rearrange preempt_disable/enable() callsAnanth N Mavinakayanahalli
The following set of patches are aimed at improving kprobes scalability. We currently serialize kprobe registration, unregistration and handler execution using a single spinlock - kprobe_lock. With these changes, kprobe handlers can run without any locks held. It also allows for simultaneous kprobe handler executions on different processors as we now track kprobe execution on a per processor basis. It is now necessary that the handlers be re-entrant since handlers can run concurrently on multiple processors. All changes have been tested on i386, ia64, ppc64 and x86_64, while sparc64 has been compile tested only. The patches can be viewed as 3 logical chunks: patch 1: Reorder preempt_(dis/en)able calls patches 2-7: Introduce per_cpu data areas to track kprobe execution patches 8-9: Use RCU to synchronize kprobe (un)registration and handler execution. Thanks to Maneesh Soni, James Keniston and Anil Keshavamurthy for their review and suggestions. Thanks again to Anil, Hien Nguyen and Kevin Stafford for testing the patches. This patch: Reorder preempt_disable/enable() calls in arch kprobes files in preparation to introduce locking changes. No functional changes introduced by this patch. Signed-off-by: Ananth N Mavinakayahanalli <ananth@in.ibm.com> Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] Move Kprobes and Oprofile to "Instrumentation Support" menuPrasanna S Panchamukhi
Andrew Morton suggested to move kprobes from kernel hacking menu, since kernel hacking menu is in-appropriate for the Kprobes. This patch moves Kprobes and Oprofile under instrumentation menu. (akpm: it's not a natural fit, but things like djprobes and the s390 guys' statistics library need a home) Signed-of-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: John Levon <levon@movementarian.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOLJohn W. Linville
The current ia64 implementation of dma_get_cache_alignment does not work for modules because it relies on a symbol which is not exported. Direct access to a global is a little ugly anyway, so this patch re-implements dma_get_cache_alignment in a manner similar to what is currently used for x86_64. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-31manual update from upstream:Tony Luck
Applied Al's change 06a544971fad0992fe8b92c5647538d573089dd4 to new location of swiotlb.c Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-30[PATCH] fix missing includesTim Schmielau
I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] jiffies_64 cleanupThomas Gleixner
Define jiffies_64 in kernel/timer.c rather than having 24 duplicated defines in each architecture. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] unify sys_ptrace prototypeChristoph Hellwig
Make sure we always return, as all syscalls should. Also move the common prototype to <linux/syscalls.h> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] memory hotplug locking: node_size_lockDave Hansen
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 <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: flush_tlb_range outside ptlockHugh Dickins
There was one small but very significant change in the previous patch: mprotect's flush_tlb_range fell outside the page_table_lock: as it is in 2.4, but that doesn't prove it safe in 2.6. On some architectures flush_tlb_range comes to the same as flush_tlb_mm, which has always been called from outside page_table_lock in dup_mmap, and is so proved safe. Others required a deeper audit: I could find no reliance on page_table_lock in any; but in ia64 and parisc found some code which looks a bit as if it might want preemption disabled. That won't do any actual harm, so pending a decision from the maintainers, disable preemption there. Remove comments on page_table_lock from flush_tlb_mm, flush_tlb_range and flush_tlb_page entries in cachetlb.txt: they were rather misleading (what generic code does is different from what usually happens), the rules are now changing, and it's not yet clear where we'll end up (will the generic tlb_flush_mmu happen always under lock? never under lock? or sometimes under and sometimes not?). Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: init_mm without ptlockHugh Dickins
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 <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: ia64 use expand_upwardsHugh Dickins
ia64 has expand_backing_store function for growing its Register Backing Store vma upwards. But more complete code for this purpose is found in the CONFIG_STACK_GROWSUP part of mm/mmap.c. Uglify its #ifdefs further to provide expand_upwards for ia64 as well as expand_stack for parisc. The Register Backing Store vma should be marked VM_ACCOUNT. Implement the intention of growing it only a page at a time, instead of passing an address outside of the vma to handle_mm_fault, with unknown consequences. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: vm_stat_account unshackledHugh Dickins
The original vm_stat_account has fallen into disuse, with only one user, and only one user of vm_stat_unaccount. It's easier to keep track if we convert them all to __vm_stat_account, then free it from its __shackles. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28Merge branch 'release' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
2005-10-28[IA64] fix warning unused variable `g'Tony Luck
4ac0068f44f192f2de95a7bb36df3e19767a45fb forgot to delete the declaration of this variable which is no longer used. Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-28Pull optimize-ptrace-threads into release branchTony Luck
2005-10-28Pull fix-slow-tlb-purge into release branchTony Luck
2005-10-28Pull fix-bte-copy into release branchTony Luck
2005-10-28Pull xpc-disengage into release branchTony Luck
2005-10-28Pull for-each-cpu into release branchTony Luck
2005-10-28Pull asm-slot-fix into release branchTony Luck
2005-10-28Pull proc-cpuinfo-siblings into release branchTony Luck
2005-10-28Pull big-sim-disk into release branchTony Luck
2005-10-28Pull sparsemem-v5 into release branchTony Luck
2005-10-28Pull new-efi-memmap into release branchTony Luck
2005-10-28Pull define-node-cleanup into release branchTony Luck
2005-10-28Pull sn_pci_legacy_read-write into release branchTony Luck
2005-10-28Pull acpi-produce-consume into release branchTony Luck
2005-10-28Pull update-default-configs into release branchTony Luck
2005-10-28Pull move-iosapic-to-acpi into release branchTony Luck
2005-10-28Pull ar-k0-usage into release branchTony Luck
2005-10-28Pull 1024-cpu into release branchTony Luck
2005-10-28Pull hp-machvec into release branchTony Luck
2005-10-28Pull altix-mmr into release branchTony Luck
2005-10-28Pull altix-fpga-reset into release branchTony Luck
2005-10-28[PATCH] gfp_t: remaining bits of arch/*Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28[PATCH] gfp_t: dma-mapping (ia64)Al Viro
... and related annotations for amd64 - swiotlb code is shared, but prototypes are not. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-27[IA64] ptrace - find memory sharers on children listCliff Wickman
In arch/ia64/kernel/ptrace.c there is a test for a peek or poke of a register image (in register backing storage). The test can be unnecessarily long (and occurs while holding the tasklist_lock). Especially long on a large system with thousands of active tasks. The ptrace caller (presumably a debugger) specifies the pid of its target and an address to peek or poke. But the debugger could be attached to several tasks. The idea of find_thread_for_addr() is to find whether the target address is in the RBS for any of those tasks. Currently it searches the thread-list of the target pid. If that search does not find a match, and the shared mm-struct's user count indicates that there are other tasks sharing this address space (a rare occurrence), a search is made of all the tasks in the system. Another approach can drastically shorten this procedure. It depends upon the fact that in order to peek or poke from/to any task, the debugger must first attach to that task. And when it does, the attached task is made a child of the debugger (is chained to its children list). Therefore we can search just the debugger's children list. Signed-off-by: Cliff Wickman <cpw@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-27[IA64] - Avoid slow TLB purges on SGI Altix systemsDean Roe
flush_tlb_all() can be a scaling issue on large SGI Altix systems since it uses the global call_lock and always executes on all cpus. When a process enters flush_tlb_range() to purge TLBs for another process, it is possible to avoid flush_tlb_all() and instead allow sn2_global_tlb_purge() to purge TLBs only where necessary. This patch modifies flush_tlb_range() so that this case can be handled by platform TLB purge functions and updates ia64_global_tlb_purge() accordingly. sn2_global_tlb_purge() now calculates the region register value from the mm argument introduced with this patch. Signed-off-by: Dean Roe <roe@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64-SGI] fix bte_copy() calling get_nasid() while preemptibleRuss Anderson
bte_copy() calls calls get_nasid(), which will get flagged if preemption if enabled. raw_smp_processor_id() is used instead. It is OK if we migrate off node. Signed-off-by: Russ Anderson (rja@sgi.com) Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64-SGI] cleanup the way XPC locates the reserved pageDean Nelson
Eliminate the passing in of a scratch buffer used for locating the reserved page setup for XPC. Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64-SGI] XPC changes to support more than 2k nasidsDean Nelson
XPC needs to be changed to support up to 16k nasids on an SGI Altix system. Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64-SGI] fixes for XPC disengage and open/close protocolDean Nelson
This patch addresses a few issues with the open/close protocol that were revealed by the newly added disengage functionality combined with more extensive testing. Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64] another place to use for_each_cpu_mask() in arch/ia64hawkes@sgi.com
In arch/ia64 change the explicit use of a for-loop using NR_CPUS into the general for_each_online_cpu() construct. This widens the scope of potential future optimizations of the general constructs, as well as takes advantage of the existing optimizations of first_cpu() and next_cpu(), which is advantageous when the true CPU count is much smaller than NR_CPUS. Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64] wider use of for_each_cpu_mask() in arch/ia64hawkes@sgi.com
In arch/ia64 change the explicit use of for-loops and NR_CPUS into the general for_each_cpu() or for_each_online_cpu() constructs, as appropriate. This widens the scope of potential future optimizations of the general constructs, as well as takes advantage of the existing optimizations of first_cpu() and next_cpu(). Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64] Fix 2.6 kernel for the new ia64 assemblerH. J. Lu
The new ia64 assembler uses slot 1 for the offset of a long (2-slot) instruction and the old assembler uses slot 2. The 2.6 kernel assumes slot 2 and won't boot when the new assembler is used: http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433 This patch will work with either slot 1 or 2. Patch provided by H.J. Lu Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64] fix siblings field value in /proc/cpuinfoSiddha, Suresh B
Fix the "siblings" field value in /proc/cpuinfo so that it now shows the number of siblings as seen by OS, instead of what is available from hardware perspective. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-10-25[IA64] Allow simulator to use bigger disksPeter Chubb
The simscsi code at present overflows an int if it's given a large disk image. The attached patch increases the possible size to 128G. While it's unlikely that anyone will want to use SKI with such a large drive, the same framework is currently being used for various virtualisation experiments. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Signed-off-by: Tony Luck <tony.luck@intel.com>