summaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] auxiliary vector cleanupsH. J. Lu2005-09-071-0/+4
| | | | | | | | | | | | The size of auxiliary vector is fixed at 42 in linux/sched.h. But it isn't very obvious when looking at linux/elf.h. This patch adds AT_VECTOR_SIZE so that we can change it if necessary when a new vector is added. Because of include file ordering problems, doing this necessitated the extraction of the AT_* symbols into a standalone header file. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] compat: be more consistent about [ug]id_tStephen Rothwell2005-09-071-8/+10
| | | | | | | | | | | | | | | | | | | | When I first wrote the compat layer patches, I was somewhat cavalier about the definition of compat_uid_t and compat_gid_t (or maybe I just misunderstood :-)). This patch makes the compat types much more consistent with the types we are being compatible with and hopefully will fix a few bugs along the way. compat type type in compat arch __compat_[ug]id_t __kernel_[ug]id_t __compat_[ug]id32_t __kernel_[ug]id32_t compat_[ug]id_t [ug]id_t The difference is that compat_uid_t is always 32 bits (for the archs we care about) but __compat_uid_t may be 16 bits on some. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] FUTEX_WAKE_OP: pthread_cond_signal() speedupJakub Jelinek2005-09-071-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ATM pthread_cond_signal is unnecessarily slow, because it wakes one waiter (which at least on UP usually means an immediate context switch to one of the waiter threads). This waiter wakes up and after a few instructions it attempts to acquire the cv internal lock, but that lock is still held by the thread calling pthread_cond_signal. So it goes to sleep and eventually the signalling thread is scheduled in, unlocks the internal lock and wakes the waiter again. Now, before 2003-09-21 NPTL was using FUTEX_REQUEUE in pthread_cond_signal to avoid this performance issue, but it was removed when locks were redesigned to the 3 state scheme (unlocked, locked uncontended, locked contended). Following scenario shows why simply using FUTEX_REQUEUE in pthread_cond_signal together with using lll_mutex_unlock_force in place of lll_mutex_unlock is not enough and probably why it has been disabled at that time: The number is value in cv->__data.__lock. thr1 thr2 thr3 0 pthread_cond_wait 1 lll_mutex_lock (cv->__data.__lock) 0 lll_mutex_unlock (cv->__data.__lock) 0 lll_futex_wait (&cv->__data.__futex, futexval) 0 pthread_cond_signal 1 lll_mutex_lock (cv->__data.__lock) 1 pthread_cond_signal 2 lll_mutex_lock (cv->__data.__lock) 2 lll_futex_wait (&cv->__data.__lock, 2) 2 lll_futex_requeue (&cv->__data.__futex, 0, 1, &cv->__data.__lock) # FUTEX_REQUEUE, not FUTEX_CMP_REQUEUE 2 lll_mutex_unlock_force (cv->__data.__lock) 0 cv->__data.__lock = 0 0 lll_futex_wake (&cv->__data.__lock, 1) 1 lll_mutex_lock (cv->__data.__lock) 0 lll_mutex_unlock (cv->__data.__lock) # Here, lll_mutex_unlock doesn't know there are threads waiting # on the internal cv's lock Now, I believe it is possible to use FUTEX_REQUEUE in pthread_cond_signal, but it will cost us not one, but 2 extra syscalls and, what's worse, one of these extra syscalls will be done for every single waiting loop in pthread_cond_*wait. We would need to use lll_mutex_unlock_force in pthread_cond_signal after requeue and lll_mutex_cond_lock in pthread_cond_*wait after lll_futex_wait. Another alternative is to do the unlocking pthread_cond_signal needs to do (the lock can't be unlocked before lll_futex_wake, as that is racy) in the kernel. I have implemented both variants, futex-requeue-glibc.patch is the first one and futex-wake_op{,-glibc}.patch is the unlocking inside of the kernel. The kernel interface allows userland to specify how exactly an unlocking operation should look like (some atomic arithmetic operation with optional constant argument and comparison of the previous futex value with another constant). It has been implemented just for ppc*, x86_64 and i?86, for other architectures I'm including just a stub header which can be used as a starting point by maintainers to write support for their arches and ATM will just return -ENOSYS for FUTEX_WAKE_OP. The requeue patch has been (lightly) tested just on x86_64, the wake_op patch on ppc64 kernel running 32-bit and 64-bit NPTL and x86_64 kernel running 32-bit and 64-bit NPTL. With the following benchmark on UP x86-64 I get: for i in nptl-orig nptl-requeue nptl-wake_op; do echo time elf/ld.so --library-path .:$i /tmp/bench; \ for j in 1 2; do echo ( time elf/ld.so --library-path .:$i /tmp/bench ) 2>&1; done; done time elf/ld.so --library-path .:nptl-orig /tmp/bench real 0m0.655s user 0m0.253s sys 0m0.403s real 0m0.657s user 0m0.269s sys 0m0.388s time elf/ld.so --library-path .:nptl-requeue /tmp/bench real 0m0.496s user 0m0.225s sys 0m0.271s real 0m0.531s user 0m0.242s sys 0m0.288s time elf/ld.so --library-path .:nptl-wake_op /tmp/bench real 0m0.380s user 0m0.176s sys 0m0.204s real 0m0.382s user 0m0.175s sys 0m0.207s The benchmark is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00001.txt Older futex-requeue-glibc.patch version is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00002.txt Older futex-wake_op-glibc.patch version is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00003.txt Will post a new version (just x86-64 fixes so that the patch applies against pthread_cond_signal.S) to libc-hacker ml soon. Attached is the kernel FUTEX_WAKE_OP patch as well as a simple-minded testcase that will not test the atomicity of the operation, but at least check if the threads that should have been woken up are woken up and whether the arithmetic operation in the kernel gave the expected results. Acked-by: Ingo Molnar <mingo@redhat.com> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Jamie Lokier <jamie@shareable.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 Linus Torvalds2005-09-054-28/+42
|\
| * [SPARC]: Kill io_remap_page_range()David S. Miller2005-09-011-3/+0
| | | | | | | | | | | | | | It's been deprecated long enough and there are no in-tree users any longer. Signed-off-by: David S. Miller <davem@davemloft.net>
| * [SPARC64]: Use 'unsigned long' for port argument to I/O string ops.David S. Miller2005-08-311-12/+35
| | | | | | | | | | | | | | This kills warnings when building drivers/ide/ide-iops.c and puts us in-line with what other platforms do here. Signed-off-by: David S. Miller <davem@davemloft.net>
| * [SPARC64]: Eliminate irq_cpustat_t.David S. Miller2005-08-292-13/+7
| | | | | | | | | | | | | | We can put the __softirq_pending mask in the cpudata, no need for the silly NR_CPUS array in kernel/softirq.c Signed-off-by: David S. Miller <davem@davemloft.net>
* | [PATCH] sab: consolidate kmem_bufctl_tKyle Moffett2005-09-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | This is used only in slab.c and each architecture gets to define whcih underlying type is to be used. Seems a bit silly - move it to slab.c and use the same type for all architectures: unsigned int. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] mm: consolidate get_orderStephen Rothwell2005-09-051-14/+2
|/ | | | | | | | | | | | Someone mentioned that almost all the architectures used basically the same implementation of get_order. This patch consolidates them into asm-generic/page.h and includes that in the appropriate places. The exceptions are ia64 and ppc which have their own (presumably optimised) versions. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [NET]: Introduce SO_{SND,RCV}BUFFORCE socket optionsPatrick McHardy2005-08-291-0/+2
| | | | | | | Allows overriding of sysctl_{wmem,rmrm}_max Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: More fully work around Spitfire Errata 51.David S. Miller2005-08-294-15/+18
| | | | | | | | | | | | It appears that a memory barrier soon after a mispredicted branch, not just in the delay slot, can cause the hang condition of this cpu errata. So move them out-of-line, and explicitly put them into a "branch always, predict taken" delay slot which should fully kill this problem. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Make debugging spinlocks usable again.David S. Miller2005-08-291-16/+24
| | | | | | | | | | | | | When the spinlock routines were moved out of line into kernel/spinlock.c this made it so that the debugging spinlocks record lock acquisition program counts in the kernel/spinlock.c functions not in their callers. This makes the debugging info kind of useless. So record the correct caller's program counter and now this feature is useful once more. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: remove use of asm/segment.hKumar Gala2005-08-292-7/+0
| | | | | | | | Removed sparc64 architecture specific users of asm/segment.h and asm-sparc64/segment.h itself Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Revamp Spitfire error trap handling.David S. Miller2005-08-291-0/+82
| | | | | | | | | | | | | | | | | | | Current uncorrectable error handling was poor enough that the processor could just loop taking the same trap over and over again. Fix things up so that we at least get a log message and perhaps even some register state. In the process, much consolidation became possible, particularly with the correctable error handler. Prefix assembler and C function names with "spitfire" to indicate that these are for Ultra-I/II/IIi/IIe only. More work is needed to make these routines robust and featureful to the level of the Ultra-III error handlers. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move kernel unaligned trap handlers into assembler file.David S. Miller2005-08-191-0/+5
| | | | | | | | | | GCC 4.x really dislikes the games we are playing in unaligned.c, and the cleanest way to fix this is to move things into assembler. Noted by Al Viro. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC]: Add inotify syscall entries.David S. Miller2005-07-271-3/+3
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] Add emergency_restart()Eric W. Biederman2005-07-261-0/+6
| | | | | | | | | | | | | | | | | | When the kernel is working well and we want to restart cleanly kernel_restart is the function to use. But in many instances the kernel wants to reboot when thing are expected to be working very badly such as from panic or a software watchdog handler. This patch adds the function emergency_restart() so that callers can be clear what semantics they expect when calling restart. emergency_restart() is expected to be callable from interrupt context and possibly reliable in even more trying circumstances. This is an initial generic implementation for all architectures. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [SPARC64]: Move syscall success and newchild state out of thread flags.David S. Miller2005-07-243-13/+15
| | | | | | | | | These two bits were accesses non-atomically from assembler code. So, in order to eliminate any potential races resulting from that, move these pieces of state into two bytes elsewhere in struct thread_info. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Privatize sun5_timer.David S. Miller2005-07-241-41/+0
| | | | | | | It is only used by some localized code in irq.c, and also delete enable_prom_timer() as that is totally unused. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill totally unused inline functions from asm/spitfire.hDavid S. Miller2005-07-241-130/+0
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Simplify asm/rwsem.h slightly.David S. Miller2005-07-241-44/+4
| | | | | | | | | rwsem_atomic_update and rwsem_atomic_add can be implemented straightly using atomic_*() routines. Also, rwsem_cmpxchgw() is totally unused, kill it. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Non-atomic bitops do not need volatile operationsDavid S. Miller2005-07-241-28/+28
| | | | | | | | | Noticed this while comparing sparc64's bitops.h to ppc64's. We can cast the volatile memory argument to be non-volatile. While we're here, __inline__ --> inline. Signed-off-by: David S. Miller <davem@davemloft.net>
* [ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...Len Brown2005-07-121-1/+1
|\ | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| * [ACPI] PNPACPI vs sound IRQDavid Shaohua Li2005-07-121-1/+1
| | | | | | | | | | | | | | | | http://bugme.osdl.org/show_bug.cgi?id=4016 Written-by: David Shaohua Li <shaohua.li@intel.com> Acked-by: Adam Belay <abelay@novell.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | [SPARC64]: Add missing asm-sparc64/seccomp.h file.David S. Miller2005-07-111-0/+21
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Add syscall auditing support.David S. Miller2005-07-101-3/+5
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Add SECCOMP support.David S. Miller2005-07-101-1/+2
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC]: Add ioprio system call support.David S. Miller2005-07-101-2/+2
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Support CONFIG_HZDavid S. Miller2005-07-081-2/+3
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Fix enable_dma() in asm-sparc64/parport.hEddie C. Dost2005-07-061-2/+2
| | | | | | | | | | | | | | Call ebus_dma_enable() before calling ebus_dma_request(), otherwise ebus_dma_request() returns -EINVAL and enable_dma() calls BUG()... Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Do proper DMA IRQ syncing on TomatilloDavid S. Miller2005-07-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was the main impetus behind adding the PCI IRQ shim. In order to properly order DMA writes wrt. interrupts, you have to write to a PCI controller register, then poll for that bit clearing. There is one bit for each interrupt source, and setting this register bit tells Tomatillo to drain all pending DMA from that device. Furthermore, Tomatillo's with revision less than 4 require us to do a block store due to some memory transaction ordering issues it has on JBUS. Signed-off-by: David S. Miller <davem@davemloft.net>
* | [SPARC64]: Add support for IRQ pre-handlers.David S. Miller2005-07-042-44/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows a PCI controller to shim into IRQ delivery so that DMA queues can be drained, if necessary. If some bus specific code needs to run before an IRQ handler is invoked, the bus driver simply needs to setup the function pointer in bucket->irq_info->pre_handler and the two args bucket->irq_info->pre_handler_arg[12]. The Schizo PCI driver is converted over to use a pre-handler for the DMA write-sync processing it needs when a device is behind a PCI->PCI bus deeper than the top-level APB bridges. While we're here, clean up all of the action allocation and handling. Now, we allocate the irqaction as part of the bucket->irq_info area. There is an array of 4 irqaction (for PCI irq sharing) and a bitmask saying which entries are active. The bucket->irq_info is allocated at build_irq() time, not at request_irq() time. This simplifies request_irq() and free_irq() tremendously. The SMP dynamic IRQ retargetting code got removed in this change too. It was disabled for a few months now, and we can resurrect it in the future if we want. Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6Greg KH2005-06-276-26/+32
|\ \
| * | [SPARC64]: Get rid of fast IRQ feature.David S. Miller2005-06-273-14/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only real user was the assembler floppy interrupt handler, which does not need to be in assembly. This makes it so that there are less pieces of code which know about the internal layout of ivector_table[] and friends. Signed-off-by: David S. Miller <davem@davemloft.net>
| * | [SPARC64]: Avoid membar instructions in delay slots.David S. Miller2005-06-273-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, avoid membar instructions in the delay slot of a jmpl instruction. UltraSPARC-I, II, IIi, and IIe have a bug, documented in the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51 The long and short of it is that if the IMU unit misses on a branch or jmpl, and there is a store buffer synchronizing membar in the delay slot, the chip can stop fetching instructions. If interrupts are enabled or some other trap is enabled, the chip will unwedge itself, but performance will suffer. We already had a workaround for this bug in a few spots, but it's better to have the entire tree sanitized for this rule. Signed-off-by: David S. Miller <davem@davemloft.net>
* | | [PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=nAndrew Morton2005-06-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_PCI=n: In file included from include/linux/pci.h:917, from lib/iomap.c:6: include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want. include/asm/pci.h: In function `pci_dma_burst_advice': include/asm/pci.h:106: dereferencing pointer to incomplete type include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function) include/asm/pci.h:106: (Each undeclared identifier is reported only once include/asm/pci.h:106: for each function it appears in.) make[1]: *** [lib/iomap.o] Error 1 Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | | [PATCH] PCI: DMA bursting adviceDavid S. Miller2005-06-271-0/+17
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After seeing, at best, "guesses" as to the following kind of information in several drivers, I decided that we really need a way for platforms to specifically give advice in this area for what works best with their PCI controller implementation. Basically, this new interface gives DMA bursting advice on PCI. There are three forms of the advice: 1) Burst as much as possible, it is not necessary to end bursts on some particular boundary for best performance. 2) Burst on some byte count multiple. A DMA burst to some multiple of number of bytes may be done, but it is important to end the burst on an exact multiple for best performance. The best example of this I am aware of are the PPC64 PCI controllers, where if you end a burst mid-cacheline then chip has to refetch the data and the IOMMU translations which hurts performance a lot. 3) Burst on a single byte count multiple. Bursts shall end exactly on the next multiple boundary for best performance. Sparc64 and Alpha's PCI controllers operate this way. They disconnect any device which tries to burst across a cacheline boundary. Actually, newer sparc64 PCI controllers do not have this behavior. That is why the "pdev" is passed into the interface, so I can add code later to check which PCI controller the system is using and give advice accordingly. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | [PATCH] sched: cleanup context switch lockingNick Piggin2005-06-251-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of requiring architecture code to interact with the scheduler's locking implementation, provide a couple of defines that can be used by the architecture to request runqueue unlocked context switches, and ask for interrupts to be enabled over the context switch. Also replaces the "switch_lock" used by these architectures with an oncpu flag (note, not a potentially slow bitflag). This eliminates one bus locked memory operation when context switching, and simplifies the task_running function. Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] RCU: clean up a few remaining synchronize_kernel() callsPaul E. McKenney2005-06-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not all) in comments. This patch changes these synchronize_kernel() calls (and comments) to synchronize_rcu() or synchronize_sched() as follows: - arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to handle races with machine-check exceptions (synchronize_rcu() would not cut it given RCU implementations intended for hardcore realtime use. - drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to handle races with i8042_interrupt() interrupt handler. Again, synchronize_rcu() would not cut it given RCU implementations intended for hardcore realtime use. - include/*/kdebug.h comments: change to synchronize_sched() to handle races with NMIs. As before, synchronize_rcu() would not cut it... - include/linux/list.h comment: change to synchronize_rcu(), since this comment is for list_del_rcu(). - security/keys/key.c unregister_key_type(): change to synchronize_rcu(), since this is interacting with RCU read side. - security/keys/process_keys.c install_session_keyring(): change to synchronize_rcu(), since this is interacting with RCU read side. Signed-off-by: "Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [SPARC64]: Report any user access faults in termios accessors.David S. Miller2005-06-241-37/+41
| | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* | [PATCH] compat: introduce compat_time_tStephen Rothwell2005-06-231-0/+1
| | | | | | | | | | | | | | | | | | | | This patch is based on work by Carlos O'Donell and Matthew Wilcox. It introduces/updates the compat_time_t type and uses it for compat siginfo structures. I have built this on ppc64 and x86_64. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] streamline preempt_count type across archsJesper Juhl2005-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The preempt_count member of struct thread_info is currently either defined as int, unsigned int or __s32 depending on arch. This patch makes the type of preempt_count an int on all archs. Having preempt_count be an unsigned type prevents the catching of preempt_count < 0 bugs, and using int on some archs and __s32 on others is not exactely "neat" - much nicer when it's just int all over. A previous version of this patch was already ACK'ed by Robert Love, and the only change in this version of the patch compared to the one he ACK'ed is that this one also makes sure the preempt_count member is consistently commented. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] Hugepage consolidationDavid Gibson2005-06-212-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lot of the code in arch/*/mm/hugetlbpage.c is quite similar. This patch attempts to consolidate a lot of the code across the arch's, putting the combined version in mm/hugetlb.c. There are a couple of uglyish hacks in order to covert all the hugepage archs, but the result is a very large reduction in the total amount of code. It also means things like hugepage lazy allocation could be implemented in one place, instead of six. Tested, at least a little, on ppc64, i386 and x86_64. Notes: - this patch changes the meaning of set_huge_pte() to be more analagous to set_pte() - does SH4 need s special huge_ptep_get_and_clear()?? Acked-by: William Lee Irwin <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] smp_processor_id() cleanupIngo Molnar2005-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a number of smp_processor_id() cleanup ideas that Arjan van de Ven and I came up with. The previous __smp_processor_id/_smp_processor_id/smp_processor_id API spaghetti was hard to follow both on the implementational and on the usage side. Some of the complexity arose from picking wrong names, some of the complexity comes from the fact that not all architectures defined __smp_processor_id. In the new code, there are two externally visible symbols: - smp_processor_id(): debug variant. - raw_smp_processor_id(): nondebug variant. Replaces all existing uses of _smp_processor_id() and __smp_processor_id(). Defined by every SMP architecture in include/asm-*/smp.h. There is one new internal symbol, dependent on DEBUG_PREEMPT: - debug_smp_processor_id(): internal debug variant, mapped to smp_processor_id(). Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new lib/smp_processor_id.c file. All related comments got updated and/or clarified. I have build/boot tested the following 8 .config combinations on x86: {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT} I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other architectures are untested, but should work just fine.) Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [SPARC64]: Add prefetch support.David S. Miller2005-06-211-0/+34
|/ | | | | | | | | | | The implementation is optimal for UltraSPARC-III and later. It will work, however suboptimally, on UltraSPARC-II and be treated as a NOP on UltraSPARC-I. It is not worth code patching this thing as the highest cost is the code space, and code patching cannot eliminate that. Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] AGP fix for Xen VMMKeir Fraser2005-06-071-0/+10
| | | | | | | | | | | | | | | | | | | When Linux is running on the Xen virtual machine monitor, physical addresses are virtualised and cannot be directly referenced by the AGP GART. This patch fixes the GART driver for Xen by adding a layer of abstraction between physical addresses and 'GART addresses'. Architecture-specific functions are also defined for allocating and freeing the GATT. Xen requires this to ensure that table really is contiguous from the point of view of the GART. These extra interface functions are defined as 'no-ops' for all existing architectures that use the GART driver. Signed-off-by: Keir Fraser <keir@xensource.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [SPARC64]: Fix streaming buffer flushing on PCI and SBUS.David S. Miller2005-05-312-3/+7
| | | | | | | | | | | | | Firstly, if the direction is TODEVICE, then dirty data in the streaming cache is impossible so we can elide the flush-flag synchronization in that case. Next, the context allocator is broken. It is highly likely that contexts get used multiple times for different dma mappings, which confuses the strbuf flushing code and makes it run inefficiently. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add boot option to force UltraSPARC-III P-Cache on.David S. Miller2005-05-231-0/+3
| | | | | | | | | | | | | | | | Older UltraSPARC-III chips have a P-Cache bug that makes us disable it by default at boot time. However, this does hurt performance substantially, particularly with memcpy(), and the bug is _incredibly_ obscure. I have never seen it triggered in practice, ever. So provide a "-P" boot option that forces the P-Cache on. It taints the kernel, so if it does trigger and cause some data corruption or OOPS, we will find out in the logs that this option was on when it happened. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill useless __pte_alloc_one_kernel indirectionChristoph Hellwig2005-05-051-7/+2
| | | | | | warning: untested, but it there's not too much chance for screwups Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] asm/signal.h unificationAl Viro2005-05-041-15/+1
| | | | | | | | | | | | | | | | | New file - asm-generic/signal.h. Contains declarations of __sighandler_t, __sigrestore_t, SIG_DFL, SIG_IGN, SIG_ERR and default definitions of SIG_BLOCK, SIG_UNBLOCK and SIG_SETMASK. asm-*/signal.h switched to including it. The only exception is asm-parisc/signal.h that wants its own declaration of __sighandler_t; that one is left as-is. asm-ppc64/signal.h required one more thing - unlike everybody else it used __sigrestorer_t instead of usual __sigrestore_t. PPC64 switched to common spelling. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
OpenPOWER on IntegriCloud