canonizer / libgpuvm Goto Github PK

Add API support for arrays initially located on device. Such arrays are not copied to device during their first on-device use, and initially have their memory protected. If they are modified on host before being used on device, however, then they are unprotected and treated as other regular arrays

otherwise, the thread holding the write lock will be suspended until GC is over. And since handling SIGSEGV during GC requires reader lock, the situation becomes deadlock-prone

sometimes, arrays are used for one-sided communication only, e.g. device -> host or host -> device. As they can be still modified on both sides, however, general way of handling them will require copying in both directions. It is possible, though, to add a flag indicating that arrays are copied one side only:

GPUVM_HOST_TO_DEVICE // copied host -> device
GPUVM_DEVICE_TO_HOST // copied device -> host

...
gpuvm_link(harr, sz, idev, darr, GPUVM_ON_HOST | GPUVM_HOST_TO_DEVICE);

typically, host arrays are mapped into device buffers. However, performance tests indicate that sometimes more performance is provided by textures (images). An API support is therefore needed to map host arrays to images, with the same set of features as supported for mapping arrays into buffers

Some kernels use some of the arrays read-only, i.e. they do not modify them. While this is difficult to detect at runtime, this can be easily detected at compile time by the language. The information is then passed to runtime via API flags.

Read-only can be handled in a more relaxed way:

• they are protected from writing only, reading on host does not cause SIGSEGV and data copying
• they can be used simultaneously by multiple devices

Linux, AMD APP SDK 2.5, HD 5830 segfaults from time to time when running a single-threaded sample on a single GPU. Note that it has never segfaulted under NUDA (large arrays?), and there are no problems when running 2 threads simultaneously on a single GPU. There are also no problems on Linux with NVidia GPUs

Add support for transferring only necessary parts of the region back to host

sometimes, an array is used to transfer data one way only, host -> device or device -> host. In this case, there's no need to copy data in opposite direction; however, this copying is still done. In order to avoid unnecessary copying, it is possible to add ability to discard data, e.g.:

void gpuvm_discard(void *ptr, int flags, unsigned dev);

if data is discarded on device, then protection on host is removed, and host data is considered actual; device data is not copied back. If data is going to be overwritten on host, it saves one data copy

in multi-threaded version, stopping OpenCL working threads results in application deadlock. Avoid doing it by noticing which threads are created by OpenCL runtime, and not stopping those threads

use balancing trees (i.e., AVL trees) for maps inside libgpuvm. Such maps include mapping ranges to regions and mapping thread ids to per-thread locking semaphores. AVL trees will increase performance mildly

Mac OS X Lion, Apple SDK (OpenCL 1.1), ATI HD4670 - 2-threaded version of the test rarely deadlocks. Note that there are no problems with single-GPU test.

Also, there is a problem with CPU OpenCL. This one, however, may be caused entirely by stopping currently running OpenCL threads, and thus can hardly be fixed.

try to replace semaphores with combinations of mutexes with conditional variables. In some cases, i.e. thread blocking, simple mutexes (with "cocking up") will do

the older 2 readdir() system call (not 3 readdir(), which is C library call), which is currently used, is not available on 64-bit linux systems, so use the supported call

it will use unnamed POSIX semaphores on linux, and mach semaphores on Darwin (because, surprisingly, there are no unnamed POSIX semaphores on Darwin!). Hope it will work fast...

It is useful, so that application doesn't have to maintain it's separate table

make data on host up-to-date before unlinking the host array. Also, remove any remaining protection. This can be accomplished by doing "three-region-salute" before unlink proper

There appear to be deadlocks in some samples on some devices:

1. add-arrays-ngpu (NVidia, rather often)
2. add-arrays-ondev (NVidia rarely, AMD almost immediately)

I was not able to find any bugs on NVidia for add-arrays or add-arrays-ro samples.

All bugs appear in the form of deadlock, and never as false data read. As to the causes of the bug, I suspect linux futexes, i.e. deadlock always appears as a futex wait. Sometimes, however, a deadlock appears as a suspended tgkill() syscall. It might be an error in Linux futex() call, although my own code is worth checking first

create a version of libgpuvm which is based on malloc hooking and creating an alternative map for regions and arrays being handled. An alternative map can be (may be!) created using /proc//mem file

Implement true device-side caching of arrays. That is, automatically allocating support buffers in GPU when host array is first used on-GPU, and deallocating them in case of memory shortage

add gpuvm_ctl() call to control values of various parameters, such as:

• mono GC signal number
• whether to block mono GC signal on entering write lock
• whether to sync data back on unlink
• ...

make thread stopping non-racing. Currently, stopping is implemented with a single semaphore; for a thread to stop, it is sent a signal. In the signal handler, the thread waits on a semaphore, which is raised when the threads can be resumed. However, if there are 2 threads, say, 1 and 2, it is possible for thread 1 to unblock, block again and then "eat" semaphore raising which was intended for thread 2. Thus, thread 1 does not get blocked when it is assumed to, and incorrect results follow.

To avoid this, a different scheme needs to be implemented for thread stopping/resuming, so that a stopped thread cannot "eat" a resume directed to another thread.