What's wrong with fbdev drivers?

Moderators: mdrjr, odroid

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Mon May 15, 2017 2:44 pm

Updated:
https://github.com/OtherCrashOverride/XU4VideoCube/tree/kernel4.9
https://github.com/OtherCrashOverride/XU4VideoCube/commits/kernel4.9

The code is a mess. :oops: I will clean it up in the future.

[edit]
posted wrong link. Added the branch link.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby memeka » Mon May 15, 2017 3:16 pm

using GST_GL_WINDOW=x11 GST_GL_API=gles2 GST_GL_PLATFORM=egl with glimagesink or using clutterautovideosink should make use of zero-copy, as i understand from gst documentation.
according to https://gstreamer.freedesktop.org/data/ ... esink.html, input can be in this possible formats:

Code: Select all
video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string){ RGBA, BGRA, RGBx, BGRx, ARGB, ABGR, xRGB, xBGR, RGB, BGR, RGB16, BGR16, AYUV, I420, YV12, NV12, NV21, YUY2, UYVY, Y41B, Y42B, Y444, GRAY8, GRAY16_LE, GRAY16_BE }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

video/x-raw(memory:SystemMemory, meta:GstVideoOverlayComposition), format=(string){ RGBA, BGRA, RGBx, BGRx, ARGB, ABGR, xRGB, xBGR, RGB, BGR, RGB16, BGR16, AYUV, I420, YV12, NV12, NV21, YUY2, UYVY, Y41B, Y42B, Y444, GRAY8, GRAY16_LE, GRAY16_BE }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

video/x-raw(meta:GstVideoGLTextureUploadMeta, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

video/x-raw(memory:GLMemory), format=(string){ RGBA, BGRA, RGBx, BGRx, ARGB, ABGR, xRGB, xBGR, RGB, BGR, RGB16, BGR16, AYUV, I420, YV12, NV12, NV21, YUY2, UYVY, Y41B, Y42B, Y444, GRAY8, GRAY16_LE, GRAY16_BE }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

video/x-raw, format=(string){ RGBA, BGRA, RGBx, BGRx, ARGB, ABGR, xRGB, xBGR, RGB, BGR, RGB16, BGR16, AYUV, I420, YV12, NV12, NV21, YUY2, UYVY, Y41B, Y42B, Y444, GRAY8, GRAY16_LE, GRAY16_BE }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

video/x-raw(meta:GstVideoGLTextureUploadMeta), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]


but i am not sure how to check to make sure
User avatar
memeka
 
Posts: 3769
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Tue May 16, 2017 3:40 am

What I see from my investigation, is that Kodi is using 100% of cpu even being completely idle. It's enough to heat up EGL layer a little, for example moving a cursor to a menu item with a long name, triggering the "running title" effect on it, and the cpu goes sky high and stays there.
doing strace on the thread that uses 150% cpu it seems it does gettimeofday, clock_gettime 30 times after, then ioctl, write, read with result "Resource temporarily unavailable" and then the same thing over.
It's really tricky to understand what exactly is wrong here...
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby meveric » Tue May 16, 2017 5:27 am

Have you compared the same on the 3.10 Kernel to see what it does there at the same time? Maybe gettimeofday / clock_gettime is not working correctly?
User avatar
meveric
 
Posts: 7958
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Tue May 16, 2017 7:26 am

So far I probably has one question I don't really know how to address. To @mdrjr probably: there are two directories in drivers/gpu/arm/midgard/platform, exynos5422 and odroid5422. The first one has absolutely nothing in it as functions, it's a pure stub, and kernel uses it. Is it supposed to be so?
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby mdrjr » Tue May 16, 2017 7:33 am

OverSun wrote:So far I probably has one question I don't really know how to address. To @mdrjr probably: there are two directories in drivers/gpu/arm/midgard/platform, exynos5422 and odroid5422. The first one has absolutely nothing in it as functions, it's a pure stub, and kernel uses it. Is it supposed to be so?


That's correct :)
exynos5422 is just a stub (we currently use it) devfreq addressed Mali frequency
odroid5422 is a impl that I've wrote but not in use anymore in favor of having devfreq and letting the Mali driver itself handle this.
mdrjr
Site Admin
 
Posts: 11640
Joined: Fri Feb 22, 2013 11:34 pm
Location: Brazil
languages_spoken: english, portuguese
ODROIDs: -

Re: What's wrong with fbdev drivers?

Unread postby streetboy » Mon May 22, 2017 5:58 pm

Any update? I want to see 1080p videos on Kernel 4.9 image with Kodi or gstreamer.
User avatar
streetboy
 
Posts: 186
Joined: Tue Feb 26, 2013 6:43 pm
languages_spoken: english
ODROIDs: ODROID-X,U2,XU3-Lite
C1, XU4

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Mon May 22, 2017 6:11 pm

The update is - I'm back from a week vacation and going to continue looking into that.
So far the video quality is at 90%. Not ideal, but very almost there.
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Mon May 22, 2017 6:24 pm

While I am not working on Kodi, I did spend several hours over the weekend examining MFC as part of my moonlight-embedded port.

The end result is that I could only achieve 1080p@30 with "zero copy" rendering when attempting to respect VSYNC. This produced far more questions than answers for me. Without waiting for VSYNC, the system is fast enough to keep up at 60fps. When VSYNC is introduce, the delay of dequeing buffers (not using them since it takes the same amount of time with or without VSYNC) results in degraded MFC performance. In my XU4VideoCube tests, it can be seen that MFC produces erratic frame rates. Sometimes its very fast (110fps), sometimes is quite slow (40fps).

My best guess at the moment is that MFC is dynamically throttled based on some exterior stimulus. I do not know if it is temperature or memory "pressure". I followed the MFC trip points into the kernel where they meet what is called "noc" (Network-On-Chip). That is the point where it all stopped making sense to me.

Note: I verified that our firmware is the latest present upstream. I also verified that our MFC is version 8. The "max clock" appears to be 330Mhz, but removing all other trip points causes MFC to lock up the board within a couple of frames. I "fixed" the clock as low as 167Mhz, but it still locked up although seeming a couple frames later than at 330Mhz. The "noc" is what determines the operating "trip point".

https://github.com/hardkernel/linux/blo ... #L970-L976
https://github.com/hardkernel/linux/blo ... 1126-L1144
https://github.com/hardkernel/linux/blo ... #L183-L186
https://github.com/hardkernel/linux/blo ... #L155-L161
https://github.com/hardkernel/linux/blo ... #L250-L272
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby memeka » Mon May 22, 2017 7:06 pm

In 4.9 MFC is not using cma anymore, but is dynamically allocating memory on runtime...
You think this would affect performance?
User avatar
memeka
 
Posts: 3769
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Mon May 22, 2017 7:46 pm

MFC has 2 IOMMUs: "left" and "right". It can use any memory as if it were CMA through the hardware IOMMUs.

I tested giving it more v4l2 buffers, but it seems to only ever use 18 based on what is seen in debugging. The math really doesn't add up. With a 60fps source and a 60fps display and 18 buffers, that means there should be up to 18 frames of latency tolerance. When the source is "real time", as in moonlight embedded, the latency constantly increases. I even tried "throwing away" all but the most current buffer which should re-establish synchronization yet it persisted. The observations are really puzzling. Its as if MFC is somehow "throttled" adding latency.

For Kodi, it may be possible to mitigate it by "pre-rolling" a large buffer. This is not possible for moonlight-embedded since games (and gamers) are latency sensitive.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Tue May 23, 2017 1:29 am

Did you try to put raw source instead of MFC CAPTURE sink as an experiment? Or somehow replace MFC with something that is known to be reliable? like ffmpeg with low resolution source...
Because the behaviour I see is that everything become slower when EGL output is used. It just produces enormous starvation if EGL layer is used as 2D accelerated surface. No difference is it MFC or light enough ffmpeg source not to hog the CPU by decoding, the output is the same.
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 11:15 am

OverSun wrote:Or somehow replace MFC with something that is known to be reliable?

Earlier versions of moonlight-embedded used SDL+FFMPEG. This resulted in 720p@30 if I recall correctly. I have not personally tested it on kernel 4.9.y + G2D enabled Armsoc.

OverSun wrote:It just produces enormous starvation if EGL layer is used as 2D accelerated surface.

I see this correlation too. However, I think the same happens if you replace EGL with a memcpy or sleep. I need to test whether MFC continues to produce frames when buffers are not returned. With 18 buffers, I should get back 18 frames out of it if I never return the buffers to it. I will post the result of this test after completion.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby meveric » Tue May 23, 2017 2:56 pm

crashoverride wrote:
OverSun wrote:Or somehow replace MFC with something that is known to be reliable?

Earlier versions of moonlight-embedded used SDL+FFMPEG. This resulted in 720p@30 if I recall correctly.

That's true for the upstream sources.
With the patches from @AreaScout for multithreadded ffmpeg and optimized GLESv2 handling in SDL2 moonlight was running in 1080p@60Hz on the XU3/XU4.
User avatar
meveric
 
Posts: 7958
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 3:41 pm

[edit: DISREGARD the following. It turns out the resolution was 720p@60]

... and the story continues to get stranger!

I was preparing the test I mentioned and needed to instrument when MFC produced a frame. I added a' printf("MFC: decoded frame.\n");' right before this line:
https://github.com/OtherCrashOverride/m ... o.cpp#L129
When ever MFC produces a frame, the message is printed.

With the above modification, MFC is now working at 1080p@60. I confirmed VSYNC is still active in the code.

I will continue investigating, but the observations really do not make any sense. Anyone have any theories?
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 3:51 pm

Ok, the results of the test where MFC buffers are not returned is as follows:
Code: Select all
Decode thread started.
MFC: width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa4310528, width=1920, height=1088
MFC: decoded frame.
MFC: decoded frame.
MFC: decoded frame.
EGLImageKHR = 0xad235358, width=1920, height=1088
Network dropped end of a frame
Waiting for IDR frame
MFC: decoded frame.
IDR frame request sent
MFC: decoded frame.
EGLImageKHR = 0xa4316878, width=1920, height=1088
Waiting for IDR frame


This sequence of events is interesting:
1) MFC produces a frame.
2) The frame buffer has not been seen before, so an EGLImage is created for it.
3) MFC produces a frame. It appears to re-use the buffer of the first frame.
4) MFC produces another frame. It also appears to re-use the buffer of the first frame.

This is what I believe could be the issue. Although MFC has several buffers. It re-uses them. This would cause MFC to block until the buffer is returned. This, in turn, would make it latency sensitive to VSYNC, EGL, memcpy, etc. Anything that delays returning a buffer also stalls MFC.

[edit]
Further testing reveals the starting sequence is due to the render thread "spinning up". So there goes another theory out the window:
Code: Select all
Decode thread started.
MFC: width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5b10528, width=1920, height=1088
MFC: decoded frame.
Network dropped end of a frame
Waiting for IDR frame
IDR frame request sent
MFC: decoded frame.
EGLImageKHR = 0xad235358, width=1920, height=1088
MFC: decoded frame.
MFC: decoded frame.
Waiting for IDR frame
EGLImageKHR = 0xa5b16878, width=1920, height=1088
MFC: decoded frame.
MFC: decoded frame.
MFC: decoded frame.
EGLImageKHR = 0xa5b659c8, width=1920, height=1088
MFC: decoded frame.
MFC: decoded frame.
EGLImageKHR = 0xa5b65a20, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5b86410, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5b86468, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5b9b590, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5b9b5d8, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5bb37a0, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5bb37f8, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5bd1f60, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5bd1fa8, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5be4fb0, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0xa5be4fe8, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0x9e81b998, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0x9e81b9e0, width=1920, height=1088
MFC: decoded frame.
EGLImageKHR = 0x9e82e9e8, width=1920, height=1088
MFC: decoded frame.
EGLImage already exists: y=58, uv=59
MFC: decoded frame.
EGLImage already exists: y=62, uv=63
MFC: decoded frame.
EGLImage already exists: y=66, uv=67
MFC: decoded frame.
EGLImage already exists: y=72, uv=73
MFC: decoded frame.
EGLImage already exists: y=76, uv=77
MFC: decoded frame.
EGLImage already exists: y=78, uv=79
MFC: decoded frame.
EGLImage already exists: y=80, uv=81
MFC: decoded frame.
EGLImage already exists: y=82, uv=83
MFC: decoded frame.
EGLImage already exists: y=84, uv=85
MFC: decoded frame.
EGLImage already exists: y=86, uv=87
MFC: decoded frame.
EGLImage already exists: y=88, uv=89
MFC: decoded frame.
EGLImage already exists: y=90, uv=91
MFC: decoded frame.
EGLImage already exists: y=92, uv=93
MFC: decoded frame.
EGLImage already exists: y=94, uv=95
MFC: decoded frame.
EGLImage already exists: y=96, uv=97
MFC: decoded frame.
EGLImage already exists: y=98, uv=99
MFC: decoded frame.
EGLImage already exists: y=100, uv=101
MFC: decoded frame.
EGLImage already exists: y=102, uv=103
MFC: decoded frame.
EGLImage already exists: y=58, uv=59
MFC: decoded frame.
EGLImage already exists: y=62, uv=63
MFC: decoded frame.
EGLImage already exists: y=66, uv=67
MFC: decoded frame.
EGLImage already exists: y=72, uv=73
MFC: decoded frame.
EGLImage already exists: y=76, uv=77
MFC: decoded frame.
EGLImage already exists: y=78, uv=79
MFC: decoded frame.
EGLImage already exists: y=80, uv=81
MFC: decoded frame.
EGLImage already exists: y=82, uv=83
MFC: decoded frame.
EGLImage already exists: y=84, uv=85
MFC: decoded frame.
EGLImage already exists: y=86, uv=87
MFC: decoded frame.
EGLImage already exists: y=88, uv=89
MFC: decoded frame.
EGLImage already exists: y=90, uv=91
MFC: decoded frame.
EGLImage already exists: y=92, uv=93
MFC: decoded frame.
EGLImage already exists: y=94, uv=95
MFC: decoded frame.
EGLImage already exists: y=96, uv=97
MFC: decoded frame.
EGLImage already exists: y=98, uv=99
MFC: decoded frame.
EGLImage already exists: y=100, uv=101
MFC: decoded frame.
EGLImage already exists: y=102, uv=103
MFC: decoded frame.
EGLImage already exists: y=58, uv=59
MFC: decoded frame.
EGLImage already exists: y=62, uv=63
MFC: decoded frame.
EGLImage already exists: y=66, uv=67
MFC: decoded frame.
EGLImage already exists: y=72, uv=73
MFC: decoded frame.
EGLImage already exists: y=76, uv=77
MFC: decoded frame.
EGLImage already exists: y=78, uv=79
MFC: decoded frame.
EGLImage already exists: y=80, uv=81
MFC: decoded frame.
EGLImage already exists: y=82, uv=83
MFC: decoded frame.
EGLImage already exists: y=84, uv=85
MFC: decoded frame.
EGLImage already exists: y=86, uv=87
MFC: decoded frame.
EGLImage already exists: y=88, uv=89
MFC: decoded frame.
EGLImage already exists: y=90, uv=91
MFC: decoded frame.
EGLImage already exists: y=92, uv=93
MFC: decoded frame.
EGLImage already exists: y=94, uv=95
MFC: decoded frame.
EGLImage already exists: y=96, uv=97
MFC: decoded frame.
EGLImage already exists: y=98, uv=99
MFC: decoded frame.
EGLImage already exists: y=100, uv=101
MFC: decoded frame.
EGLImage already exists: y=102, uv=103
MFC: decoded frame.
EGLImage already exists: y=58, uv=59
MFC: decoded frame.

The numbers (y=, uv=) are the dmabuf file descriptors.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 4:11 pm

AHA! I think I found it ...

Its a bug in my code. :oops:

If my renderer did not see a frame from MFC, it never got returned. This resulted in MFC being starved of frames. The clue was the skipped numbers in the sequence output above.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 4:32 pm

To summarize everything to this point:

@OverSun we can get 1080p@60 out of MFC+Mali. The caveat is that I had to use DMBUF+EGLImage (zero copy) to achieve it. A possible explanation is that Armsoc now use G2D. This puts a lot more memory "pressure" on the bus as rendering speed is greatly increased over the previously used memcpy.
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Tue May 23, 2017 4:54 pm

This is going to be pain in the back to implement in Kodi, X11 and fbdev also. I don't even fully understand what are you talking about. =D
Can you give me a link to the place where changes you mention as DMABUF+zerocopy are implemented? So I can maybe project it somehow to Kodi renderers...
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 5:26 pm

OverSun wrote:Can you give me a link to the place where changes you mention as DMABUF+zerocopy are implemented?

It can be found in my XU4VideoCube sample:
https://github.com/OtherCrashOverride/XU4VideoCube/commits/kernel4.9
"DMA-BUF zero-copy rendering"

First, you need to tell Video4Linux to export the buffers via DMABUF. The file descriptor is returned in "expbuf.fd". This is the handle you will pass to EGLImage:
https://github.com/OtherCrashOverride/XU4VideoCube/blob/kernel4.9/src/CodecData.h#L97-L107

Next, you create an EGLImage from that buffer handle. Note there are two DMABUF handles: one for Y and one for UV (NV12):
https://github.com/OtherCrashOverride/XU4VideoCube/blob/kernel4.9/src/Scene.cpp#L265-L282

Then, you create a texture from the EGLImage:
https://github.com/OtherCrashOverride/XU4VideoCube/blob/kernel4.9/src/Scene.cpp#L287-L301

To use the texture, you have to use a special sampler "samplerExternalOES". Other than that, it behaves the same as a regular texture:
https://github.com/OtherCrashOverride/X ... pp#L55-L66

I keep a record of the DMABUF file descriptors and the Texture created from them to avoid duplication:
https://github.com/OtherCrashOverride/XU4VideoCube/blob/kernel4.9/src/Scene.cpp#L253
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: What's wrong with fbdev drivers?

Unread postby OverSun » Tue May 23, 2017 6:14 pm

Ok, this is possible. Not easy, but I can see how this can be implemented.
Still, I honestly think that something is wrong with EGL output on 4.9 kernel, because just running Kodi without any video already takes 100% cpu on one core.
User avatar
OverSun
 
Posts: 1266
Joined: Mon Apr 29, 2013 5:12 pm
languages_spoken: english

Re: What's wrong with fbdev drivers?

Unread postby crashoverride » Tue May 23, 2017 6:41 pm

Currently, I see about 16% CPU usage in moonlight-embedded. Whatever is driving Kodi at 100% its unlikely to be EGL/GLES. I only see 100%+ usage when I do not wait for VSYNC.
Code: Select all
top - 09:30:21 up 2 days, 46 min,  3 users,  load average: 0.11, 0.20, 0.28
Tasks: 233 total,   1 running, 232 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  1.3 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2041896 total,  1129192 free,   473880 used,   438824 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1461480 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
14275 odroid    20   0  406264 203312 194272 S  16.2 10.0   0:12.77 moonlight-+
 1030 root      20   0  223420  65356  55384 S   1.3  3.2  10:18.56 Xorg
14264 root      20   0       0      0      0 S   1.3  0.0   0:01.67 kworker/u1+
14300 root       0 -20       0      0      0 S   1.3  0.0   0:00.15 kworker/u1+
13896 root      20   0       0      0      0 S   0.3  0.0   0:01.43 kworker/0:2
14306 odroid    20   0    6996   2748   2244 R   0.3  0.1   0:00.09 top
    1 root      20   0   24420   4340   2576 S   0.0  0.2   0:10.81 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.06 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:02.24 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+
    7 root      20   0       0      0      0 S   0.0  0.0   0:52.14 rcu_preempt
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.03 rcu_sched
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
   10 root      rt   0       0      0      0 S   0.0  0.0   0:00.01 migration/0
   11 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-dr+
   12 root      20   0       0      0      0 S   0.0  0.0   0:00.00 cpuhp/0
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 cpuhp/1
crashoverride
 
Posts: 3113
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Previous

Return to Ubuntu

Who is online

Users browsing this forum: No registered users and 2 guests