Message boards :
Number crunching :
Linux Intel GPU jobs run at 100% CPU.
Message board moderation
Author | Message |
---|---|
Gordon Lack Send message Joined: 23 Aug 09 Posts: 14 Credit: 727,367 RAC: 3 ![]() |
Just noticed that my Linux jobs (SETI@home v8 8.22 opencl_intel_gpu_sah) claim to require 0.00641 CPUs = 1 Intel GPU, but actually continuously consume 100% of a CPU. (Equally oddly, but "better" for me, is that a collatz GPU job claims to need 0.886 CPUs, but actually only uses 1.7% of one). PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32365 boinc 30 10 482356 321100 60340 R 100.3 4.0 2:24.35 setiathome_8.22 |
Gordon Lack Send message Joined: 23 Aug 09 Posts: 14 Credit: 727,367 RAC: 3 ![]() |
straceing the process show it doing this, very quickly... sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8e20) = 0 futex(0x1f341f0, FUTEX_WAKE_PRIVATE, 1) = 1 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8e20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8820) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8820) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8820) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8820) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8b20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8e20) = 0 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffcd63f8e20) = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 ..... |
![]() ![]() ![]() Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 ![]() ![]() |
You have fallen into the common misconception that the task identifier showing some xx percent of a cpu is what is needed to support the gpu task. It is not. It is value used only for scheduling of work sent to a host by the scheduler. Only the application itself determines how much of a cpu thread is needed to support the gpu task. Seti@Home classic workunits:20,676 CPU time:74,226 hours ![]() ![]() A proud member of the OFA (Old Farts Association) |
Gordon Lack Send message Joined: 23 Aug 09 Posts: 14 Credit: 727,367 RAC: 3 ![]() |
You have fallen into the common misconception that the task identifier showing some xx percent of a cpu is what is needed to support the gpu task. It is not. It is value used only for scheduling of work sent to a host by the scheduler.Which ignores it, from what I can see. Only the application itself determines how much of a cpu thread is needed to support the gpu task.OK. But running at 100% still seems wrong when the vast majority of syscalls as just sched_yield(). |
Richard Haselgrove ![]() Send message Joined: 4 Jul 99 Posts: 14686 Credit: 200,643,578 RAC: 874 ![]() ![]() |
You have fallen into the common misconception that the task identifier showing some xx percent of a cpu is what is needed to support the gpu task. It is not. It is value used only for scheduling of work sent to a host by the scheduler. Only the application itself determines how much of a cpu thread is needed to support the gpu task.Doesn't the display quoted originate from Linux, rather than from BOINC? Linux itself doesn't pay any attention to BOINC's estimates, internally. It simple measures what it sees. |
Gordon Lack Send message Joined: 23 Aug 09 Posts: 14 Credit: 727,367 RAC: 3 ![]() |
Doesn't the display quoted originate from Linux, rather than from BOINC? Linux itself doesn't pay any attention to BOINC's estimates, internally. It simple measures what it sees.BOINC isn't measuring anything. It's stating that its requirement for CPU usage is very low, whereas in fact it is very high. There is no way that this is going to help any scheduler. |
©2025 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.