- Jun 16, 2008
-
-
Luke Browning authored
There is a delay in the transition to the stopped state for class 2 interrupts. In some cases, the controlling thread detects the state of the spu as running, and goes back to sleep resulting in a hung application as the event is missed. This change detects the stop condition and re-generates the wakeup event after a context save. Signed-off-by:
Luke Browning <lukebrowning@us.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
Time slicing can occur at the same time as spu exception handling resulting in the wakeup of the wrong thread. This change uses the the spu's register_lock to enforce synchronization between bind/unbind and spu exception handling so that they are mutually exclusive. Signed-off-by:
Luke Browning <lukebrowning@us.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
According to the CBEA, the SPU dsisr is not updated for class 0 exceptions. spu_stopped() is testing the dsisr that was passed to it from the class 0 exception handler, so we return a false positive here. This patch cleans up the interrupt handler and erroneous tests in spu_stopped. It also removes the fields from the csa since it is not needed to process class 0 events. Signed-off-by:
Luke Browning <lukebrowning@us.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
If the spu is stopping (ie, the SPU_STATUS_RUNNING bit is still set), re-read the register to get the final stopped value. Signed-off-by:
Luke Browning <lukebrowning@us.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- May 15, 2008
-
-
FUJITA Tomonori authored
With CONFIG_VIRT_CPU_ACCOUNTING disabled, I got the following error: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c: In function 'spu_switch_log_notify': linux-2.6/arch/powerpc/platforms/cell/spufs/file.c:2542: error: implicit declaration of function 'get_tb' make[4]: *** [arch/powerpc/platforms/cell/spufs/file.o] Error 1 Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Luke Browning authored
If victim (not ctx) is in spu_run, add victim to rq. Signed-off-by:
Luke Browning <lukebrowning@us.ibm.com> Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- May 08, 2008
-
-
Christoph Hellwig authored
We need to acquire the parent i_mutex with I_MUTEX_PARENT to keep lockdep happy. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Christoph Hellwig authored
We should not requeue the victim context in find_victim if the owner is not in spu_run. It's first not needed because leaving the context on the spu is an optimization and second is harmful because it means the owner could re-enter spu_run when the context is on the runqueue and trip the BUG_ON in __spu_update_sched_info. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- May 05, 2008
-
-
Christoph Hellwig authored
Creating a spufs context or gand using spu_create should send an inotify event so that things like performance monitors have an easy way to find out about newly created contexts. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
Currently, page fault handlers don't issue a mfc restart if the context switch pending flag is set, which can leave us with a hanging DMA after a context restore. This patch introduces fault pending flag that is set by the fault handler and read by the context switch code, so that the latter can add the restart bit at the right spot, after it has successfuly saved the state of the mfc control register. Signed-off-by:
Luke Browning <lukebr@linux.vnet.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
SPU class 0 & 1 exceptions may occur in parallel, so we may end up overwriting csa.dsisr. This change adds dedicated fields for each class to the spu and the spu context so that fault data is not overwritten. Signed-off-by:
Luke Browning <lukebr@linux.vnet.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
Currently, we re-route SPU interrupts to the current cpu, which may be on a remote node. In the case of time slicing, all spu interrupts will end up routed to the same cpu, where the spusched_tick occurs. This change routes mfc interrupts to the cpu where the controlling thread last ran, provided that cpu is on the same node as the spu (otherwise don't reroute interrupts). This should improve performance and provide a more predictable environment for processing spu exceptions. In the past we have seen concurrent delivery of spu exceptions to two cpus. This eliminates that concern. Signed-off-by:
Luke Browning <lukebr@linux.vnet.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Luke Browning authored
synchronize_irq() provides the serialization for SPU_CONTEXT_SWITCH_PENDING which is read with a simple load. This routine guarantees that the relevant interrupt handlers are not running, so that the next time they do run they will see the update memory value. This must be done correctly so that exception handling code does not restart the mfc in the middle of a context switch while we are trying to atomically stop it and save state. Signed-off-by:
Luke Browning <lukebr@linux.vnet.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
There's currently no way to tell if spu_process_callback has returned with the state mutex held, as -EINTR may be returned by either the syscall or the spu_acquire fail case. Instead, just do a non-interruptible mutex_lock here. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
Currently, we update the SPU master run control bit (ie, spu_enable_spu) in spufs_run_spu before we grab the context mutex. This can result in races with other processes accessing this context's resources. This change moves the spu_enable_spu to after we have acquired the context lock. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
We currently have two issues with the MFC save code: * save_mfc_decr doesn't handle a transition of 1 -> 0 of the Ds bit * The Q bit may be stale in the CSA This change fixes the first issue by clearing the relevant bits from the MFC_CNTL value in the CSA before or-ing in the updated status. Also, we add the Q bit to the updated status. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
Currently, we can introduce invalid entries into the MFC queues: 1) context starts a DMA 2) context gets scheduled out during a DMA - kernel saves MFC queue to CSA - kernel saves 0x0 in csa->mfc_control_RW 3) context gets scheduled in - csa->mfc_control[Q] ('queues empty') isn't set, so DMA queues are restored from the CSA 4) context's DMA is completed 5) context gets scheduled out again, no DMA occuring this time - kernel sees that MFC_CNTL[Q] ('queues empty') is set, so doesn't touch saved queue data in CSA - kernel saves 0x0 in csa->mfc_control_RW 6) context gets scheduled in - csa->mfc_control[Q] ('queues empty') isn't set (we saved is as 0!), so DMA queues are restored from the CSA In this last restore, we've restored the queue status from step 2, which are now invalid. This change makes save_mfc_cntl() closer to the save/restore sequence, as specified in the CBE handbook. With changes from Luke Browning. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
When we issue a MFC purge request, we may inadvertantly clear the suspended status. This change adds the MFC_CNTL_SUSPEND_MASK when we issue a purge request, so that the suspend bit is masked out. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- May 01, 2008
-
-
Al Viro authored
Initial splitoff of the low-level stuff; taken to fdtable.h Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Apr 30, 2008
-
-
Kumar Gala authored
Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Julio M. Merino Vidal authored
The sputrace module contained a trace entry for spu_acquire_saved, but this marker was not placed anywhere. Fix this by adding a marker to the routine. Signed-off-by:
Julio M. Merino Vidal <jmerino@ac.upc.edu> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Julio M. Merino Vidal authored
Fix a typo in the marker for the find_victim function, which prevented it from being traced. It previously read find_vitim. Signed-off-by:
Julio M. Merino Vidal <jmerino@ac.upc.edu> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Julio M. Merino Vidal authored
The sputrace module contained a reference to a marker for destroy_spu_context, but this marker did not appear in the code. Fix this by adding a marker in the function. Signed-off-by:
Julio M. Merino Vidal <jmerino@ac.upc.edu> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Julio M. Merino Vidal authored
The markers facility defines the marker parameters to be of the form 'name %format'. Add parameter names to sputrace, to specify the context and %spu paramerters, instead of just specifying the '%format' part. Signed-off-by:
Julio M. Merino Vidal <jmerino@ac.upc.edu> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Christoph Hellwig authored
There are userspace instrumentation tools that need to monitor spu context switches. This patch adds a new file called 'switch_log' to each spufs context directory that can be used to monitor the context switches. Context switch in/out and exit from spu_run are monitored after the file was first opened and can be read from it. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- Apr 29, 2008
-
-
Denis V. Lunev authored
Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data be setup before gluing PDE to main tree. Add correct ->owner to proc_fops to fix reading/module unloading race. Signed-off-by:
Denis V. Lunev <den@openvz.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Apr 19, 2008
-
-
Matthew Wilcox authored
None of these files use any of the functionality promised by asm/semaphore.h. It's possible that they rely on it dragging in some unrelated header file, but I can't build all these files, so we'll have fix any build failures as they come up. Signed-off-by:
Matthew Wilcox <willy@linux.intel.com>
-
- Apr 01, 2008
-
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- Mar 28, 2008
-
-
Gerhard Stenzel authored
At present, ppu-gdb can't trace spu infomation with coredump generated by the kernel. While the core dumps notes have correct contents, they have the wrong names, as the file descriptors used to generate the note names are off-by-one. An application that opens a SPE context as fd 3, the current core dump code will generate notes like: SPU/4/mem SPU/4/regs etc. This confuses GDB, which knows it is looking for SPE context 3 (from parsing the spu_context_run system call arguments), and cannot find any notes that match context 3. This change corrects the file descriptor counting, to only increment the fd until after we've written the note name. Signed-off-by:
Gerhard Stenzel <stenzel@de.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
During the context save process, we currently save the MFC command channel after purging the MFC queues. This causes a systemsim warning, as the command channel may be in an unknown state after the purge. This change does the save before purging the MFC queues. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
During spu_process callback, we release then acquire the SPU, but keep a pointer to the local store memory. Since the context may have been scheduled out during the callback, the ls pointer may become invalid. This change reacquires the pointer to the context local store after spu_acquire()-ing, so that it isn't invalidated by a context switch. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
All of the single-value files in spufs are terminated by a newline, except for signal1_type and signal2_type. This change adds a trailing newline to these two files. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- Mar 11, 2008
-
-
Jeremy Kerr authored
At present, we can hit the BUG_ON in __spu_update_sched_info by reading the regs file of a context between two calls to spu_run. The spu_release_saved called by spufs_regs_read() is resulting in the (now non-runnable) context being placed back on the run queue, so the next call to spu_run ends up in the bug condition. This change uses the SPU_SCHED_SPU_RUN flag to only reschedule a context if it's still in spu_run(). Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
commit 4ef11014 introduced a usage of SCHED_IDLE to detect when a context is within spu_run. Instead of SCHED_IDLE (which has other meaning), add a flag to sched_flags to tell if a context should be running. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- Feb 29, 2008
-
-
Andre Detsch authored
The spu_runcntl_RW register is restored within spu_restore function. So, at the end of spu_bind_context, the SPU context is not just loaded, but running. This change corrects the state switch to account the time as USER. Signed-off-by:
Andre Detsch <adetsch@br.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Arnd Bergmann authored
There is a small race between the context save procedure and the SPU interrupt handling, where we expect all interrupt processing to have finished after disabling them, while an interrupt is still being processed on another CPU. The obvious fix is to call synchronize_irq() after disabling the interrupts at the start of the context save procedure to make sure we never access the SPU any more during an ongoing save or even after that. Thanks to Benjamin Herrenschmidt for pointing this out. Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
Currently, we get the following output from sputrace: [5.097935954] 1606: spufs_ps_nopfn__enter (thread = 1605, spu = -1) [5.097958164] 1606: spufs_ps_nopfn__insert (thread = 1605, spu = 15) [5.097973529] 1607: spufs_ps_nopfn__enter (thread = 1605, spu = -1) [5.097989174] 1607: spufs_ps_nopfn__insert (thread = 1605, spu = 14) Which leads me to believe that 160[67] is the current thread ID, and 1605 is the context backing the psmap. However, the 'current' and 'owner' tids are reversed - the 'current' tid is on the right. This change puts the current thread ID in the left-hand column instead, and renames the right to 'ctxthread'. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- Feb 27, 2008
-
-
Jeremy Kerr authored
At present, we have a situation where a context with no owner is re-scheduled by spu_forget: Thread 1: reading regs file Thread 2: context owner spu_forget() - ctx->owner = NULL - set SPU_SCHED_WAS_ACTIVE spu_acquire_saved() - context is in saved state spu_release_saved() - SPU_SCHED_WAS_ACTIVE is set, so spu_activate() the context, which now has no owner In spu_forget(), we shouldn't be requesting a re-schedule by setting SPU_SCHED_WAS_ACTIVE. This change removes the set_bit in spu_forget(), so that spu_release_saved() doesn't reinsert this destroyed context on to the run queue. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
Jeremy Kerr authored
We have a small window where a spu context may be destroyed while we're servicing a page fault (from another thread) to the context's problem state mapping. After we up_read() the mmap_sem, it's possible that the context is destroyed by its owning thread, and so the later references to ctx are invalid. This can maifest as a deadlock on the (now free()-ed) context state mutex. This change adds a reference to the context before we release the mmap_sem, so that the context cannot be destroyed. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-
- Feb 20, 2008
-
-
Andre Detsch authored
At present, the __spufs_trap_data_map and __spu_trap_data_seq functions exit if spu->flags has the SPU_CONTEXT_SWITCH_ACTIVE set. This was resulting in suprious returns from these functions, as they may be legitimately called when we have this bit set. We only use it in these two sanity checks, so this change removes the flag completely. This fixes hangs in the page-fault path of SPE apps. Signed-off-by:
Andre Detsch <adetsch@br.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org>
-