V4l2 high cpu usage

Hello, we now use the nx module to connect 4 cameras. our program is made by v4l2.
When a program is stress-test(streamon, streamclose), the CPU occupies 100%. and program freezes.

We test jetpack 4.6.1

The top command output is as follows:

How can I reduce the CPU usage

I referenced

There was no effect.

hello rlatae123,

you may try using renice utility to configure the program to have higher priority, this should ensure your program to grant CPU resources.
however, this looks unreal use-case, stress tool intent to fully occupy CPU resources.

but when i tested jetpack 4.4.1 no errors occur.

it could be our program’s fault, so we additionally tested it using v4l2-ctl

we met same error


e

hello rlatae123,

there shows discarding frame messages, which is VI driver side to drop capture buffers due to unsuccessful capture state.
have you try using renice utility to configure the program to have higher priority, is this helps?

we using renice but same error

when I debuging our program,
randomly the one video channel(ex. video0 ~ 3) is meet select timeout error between v4l2 stream on and v4l2 dqbuf

hello rlatae123,

there’re some fixes check-in to refine buffer handling for Xavier series driver.
is it possible for moving to latest release, i.e. JetPack-4.6.3/ L4T 32.7.3 for testing?

Okay I’ll test it

hello @JerryChang

we test 4.6.3

vi-output process appears first and then disappears. But the issues are the same.

randomly the one video channel(ex. video0 ~ 3) is meet select timeout error between v4l2 stream on and v4l2 dqbuf

hear are our test code

where the error occurs:

type = V4L2_TYPE;
xioctl(g_fd, VIDIOC_STREAMON, &type);

CLEAR(G_DELAY_BUF);
G_DELAY_BUF.type = V4L2_TYPE;
G_DELAY_BUF.memory = V4L2_MEMORY_MMAP;

do {
	FD_ZERO(&fds);
	FD_SET(g_fd, &fds);

	/* Timeout. */
	tv.tv_sec = 2;
	tv.tv_usec = 0;

	r = select(g_fd + 1, &fds, NULL, NULL, &tv);
} while ((r == -1 && (errno = EINTR)));
if (r == -1) { perror("select"); return errno; }

if(-1 == xioctl(g_fd, VIDIOC_DQBUF, &G_DELAY_BUF)) {
		errno_exit("VIDIOC_DQBUF");
}

our v4l2-ctl device setting:

trace log :
log.txt (7.3 MB)

we test vi5 debug

sudo echo ‘file csi5_fops.c +p’ > /sys/kernel/debug/dynamic_debug/control

but error is the same

hello rlatae123,

just for confirmation. could you please check this is related to CPU heavy loading. is it continuous stream-on/off to increase the CPU usage?
in other words, please narrow down the issue, please check you have good camera stability. is your normal camera stream use-case works as expect?

besides,
we’ll also gather resources to setup an environment to reproduce the issue locally.

so how can i test camera stability?

Can I get some advice?

hello rlatae123,

please refer to developer guide, Approaches for Validating and Testing the V4L2 Driver.
you may check… $ v4l2-ctl -d /dev/video0 --list-formats-ext for your sensor supported formats.
please see-also below sample pipelines to test your stream, please update the settings with your sensor supported formats accordingly.
for example,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

Sorry I thought the errors were gone but it wasn’t

we test v4l2-ctl command in jetpack 4.6.3

errors appear after serveral repetitions

Is this a camera problem?

error_1ch

error_3ch

@JerryChang

Is there anything else I can check?

hello rlatae123,

we cannot reproduce the same failure.
the test script also execute v4l pipelines to test camera stream repeatedly, it’s passing 1000 test cycles without failures.
in addition, our test results show consistency CPU loading, it keeps around 2% CPU usage.

may I know who’s the camera vendor, you may contact with them for digging into sensor side.

Okay I will check then I have question

  1. we test our product in jetpack 4.4.1 What’s the difference between 4.4.1 and 4.6.1

  2. Does it matter if I apply 4.4.1 to the 4.6.1 driver?

We using imx390 sensor

We ran a new test with JETPACK 5.0.2 and no errors occurred.

Right now the situation is only coming from version 4.6.x

Is there anything more suspicious than the camera sensor?

hello rlatae123,

sorry for late reply due to public holiday.

>> What’s the difference between 4.4.1 and 4.6.1
you may check release note for details, it basically bug fixes for kernel and also pre-built binaries.

>> Does it matter if I apply 4.4.1 to the 4.6.1 driver?
it may not works, because there’s version dependency between kernel layer and user-space.

>> We ran a new test with JETPACK 5.0.2 and no errors occurred.
this is great news.
however, JP-4.6.x and JP-5.0.x were using different kernel version. i.e. k-4.9 v.s. k-5.10.
besides, is it possible for using the latest JetPack release for development?

hello Jerry

I want to develop on 5.0.2 but gave up due to too long boot time.

I ran out of time and temporarily fixed the problem by modifying the code.

However, it seems that the root cause needs to be found later.