-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance issue #7
Comments
try
for CONFIG_DRM_I915_ALPHA_SUPPORT pass i915.alpha_support=1 on the kernel command line. |
I've |
To have a better idea.. here is my kernel config
Everything else is excluded. |
the config items i posted are 5.4 era. i cant help you anymore than what i stated above. try to disable all |
No problem with filing this issue here, this isn't exclusively TinyCore sw.
Your video has a lot of h264 corruption errors, so I'm not entirely sure what is from the corruption and what from the recording. But it seems to show that your shell took ~8s to show a prompt. While Xfbdev is certainly slow in comparison to Xvesa and accelerated drivers, you're right that this is greatly too slow, especially as you look like you're running on a more modern cpu. I'm afraid I don't know what could be the main issue. The DRM fbdev emulation is considered terribly slow and bad in general, so that would be my first guess, but I think many TC users use the KMS FB with Xfbdev without such issues. Try profiling? Perf or oprofile's operf should do (with root rights and the options that enable full-system and kernel profiling). |
Any particular reason why you prefer older versions? Anyway.. thank you mate, it was good to know the issue is in the kernel. |
Hello!
I think I tried Xvesa before, I don't even remember if it launch.
I think this is the first time I've heard of this :D Any guide? |
Oprofile's docs are quite good, haven't used perf much. In short, you first configure one or two sysctl options to enable wide profiling, then instead of "Xfbdev -args" you launch "operf -operfargs Xfbdev -args", run it for a bit, and using the tools then look at the results. |
This sounds interesting, but I’m skeptical that it will completely resolve the slowness. It seems tinyx isn’t utilizing the GPU, as even with minimal tasks, the CPU usage spikes significantly. My last option is to try a generic kernel configuration, but I’ve started to lose interest due to other issues such as cursor glitches, limited touchpad functionality (only the click button works), and I don't know if it possible to add my native language keymap. Thanks for your help guys, I really appreciate it. |
Update: I built a generic kernel using the sabotage configuration file, the issue still persists. |
maybe @aligrudi has some advice or tuned kernel config, as he's the author of some linux fb software.
i guess i just cant be bothered to try a new kernel and fix all the new issues that inevitably show up, when the one i use is still LTS-supported and works just fine. |
Yeah also I will revisit
Fair enough, I actually may do the same. Thanks for the reply. |
Maybe leaving this here will help
This is the build script I used via |
@rofl0r I disabled all the |
rofl0r ***@***.***> wrote:
maybe @aligrudi has some advice or tuned kernel config, as he's the author of some linux fb software.
> Any particular reason why you prefer older versions?
i guess i just cant be bothered to try a new kernel and fix all the new issues that inevitably show up, when the one i use is still LTS-supported and works just fine.
It is difficult to guess the cause of the slowness just based
on the posted video.
The CPU usage seem to be above 40%: it may be due to capturing
the screen. Does it remain so without any activity?
It takes some seconds until the shell prompt appears in opened
terminals: it cannot be directly related to the performance
of the framebuffer.
Moving terminals are not rendered fast: this may be related
to the performance of the framebuffer. Because the contents
of the windows need to be copied to the framebuffer after
each movement, that is not unexpected. However, tinyx or
Xfbdev may not be updating the framebuffer as efficiently
as possible.
Ali
|
Hello brother, I hope you're doing well.
I agree but I couldn't find another way to express the issue, I wish there was a debugging option or another way.
No, in idle it's 0% and as soon as I launch a terminal window (st) it jumps up to ~25%... in Wayland and Xorg it jumps to be ~1%. Sometimes I press Mode - Return multiple times to open multiple terminal windows, in the third and beyond it takes several seconds to open! |
I apologize for opening this issue as I'm not a TinyCore user, but this is my last resort.
For several months, I've been trying to get
tinyx
to run at full speed without success. Despite extensive research and various attempts, the performance remains slow. I've attached a video that demonstrates the issue, although it's longer than intended due to the slowness.screencast-20240912-15-44.mp4
I'm using Oasis and compiled
tinyx
from source. My window manager is a lightly customized version ofdwm
, but the problem persists with the standard version as well.In the kernel, I've enabled several framebuffer and
Xfbdev
related options, including:In one attempt, I even enabled all framebuffer-related options, but the issue persisted.
I believe debugging this problem could lead to a solution, but I'm unsure where to start.
The text was updated successfully, but these errors were encountered: