Bug 219570
| Summary: | Reading from vivid results in 100% CPU use | ||
|---|---|---|---|
| Product: | v4l-dvb | Reporter: | Artem S. Tashkinov (aros) |
| Component: | v4l-core | Assignee: | v4l-dvb_v4l-core (v4l-dvb_v4l-core) |
| Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
| Severity: | low | CC: | hverkuil |
| Priority: | P3 | ||
| Hardware: | AMD | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
Hans, please take a look. When waiting in the kthread until it is time to create the next frame, vivid uses:
while (!it_is_time)
schedule()
Which is correct, but inefficient. If no other CPU activity is ongoing, then this is equivalent to a busy loop.
I'll replace it with a wait_event_interruptible_timeout().
Thanks a lot for the patch! Fixed by: https://lore.kernel.org/linux-media/f7bc5105-332f-414b-8160-3c0ff679c608@xs4all.nl/T/#u |
I'm not sure this command should result in a 100% CPU use: ffmpeg -i /dev/video0 -f rawvideo -pixel_format yuv420p -video_size 640x360 -c:v libx264 -preset ultrafast -crf 10 /tmp/result.mkv PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 235941 root 20 R 100.0 0:11.53 vivid-000-vid-cap There's no ffmpeg in the top because it compresses so fast, it can be barely registered by top. This is reproducible in 6.12.2. My CPU is Ryzen 7 5800X and it's plenty fast. I'm almost sure reading from vivid must not result in any perceivable CPU use since it's generating a static picture. I could be totally wrong though, please advise.