Announcing a new version of MuQSS and a -ck release to go with it in concert with mainline releasing 4.8.5
4.8-ck5 patchset:
http://ck.kolivas.org/patches/4.0/4.8/4.8-ck5/
MuQSS by itself for 4.8:
4.8-sched-MuQSS_120.patch
MuQSS by itself for 4.7:
4.7-sched-MuQSS_120.patch
Git tree:
https://github.com/ckolivas/linux
This is a fairly substantial update to MuQSS which includes bugfixes for the previous version, performance enhancements, new features, and completed documentation. This will likely be the first publicly announced version on LKML.
EDIT: Announce here: LKML
New features:
- MuQSS is now a tickless scheduler. That means it can maintain its guaranteed low latency even in a build configured with a low Hz tick rate. To that end, it is now defaulting to 100Hz, and it is recommended to use this as the default choice for it leads to more throughput and power savings as well.
- Improved performance for single threaded workloads with CPU frequency scaling.
- Full NoHZ now supported. This disables ticks on busy CPUs instead of just idle ones. Unlike mainline, MuQSS can do this virtually all the time, regardless of how many tasks are currently running. However this option is for very specific use cases (compute servers running specific workloads) and not for regular desktops or servers.
- Numerous other configuration options that were previously disabled from mainline are now allowed again (though not recommended for regular users.)
- Completed documentation can now be found in Documentation/scheduler/sched-MuQSS.txt
Bugfixes:
- Fix for the various stalls some people were still experiencing, along with the softirq pending warnings.
- Fix for some loss of CPU for heavily sched_yielding tasks.
- Fix for the BFQ warning (-ck only)
Enjoy!
お楽しみ下さい
-ck
Should we enable the "Full dynticks CPU accounting" option or leave it to "Simple tick based cputime accounting" for a standard desktop system? I was reading the documentation and I'm not sure if it should be dynticks cpu accounting or tick based. Does it matter for MuQSS?
ReplyDeleteAlso to add onto that, should we use tickless idle or constant ticks for a desktop system?
DeleteI guess I will just leave them all at defaults.
DeleteThe accounting choice doesn't matter but adds slight overhead. Tickless idle should be used though.
ReplyDeleteHello,
ReplyDeletesince ck2 that replaced BFS with MuQSS I have an issue with wine:
While I play a game (Paladins) it will eventually freeze, but the rest of the computer is totally fine. Killing wine and restarting it works till the next freeze.
I see nothing in dmesg, nor in winelog, so it took me some trials to realize it was from the ck patchset, so far I've only had that issue while on ck2 to ck5.
I've tried just MuQSS, 250hz, 1000hz and preempt from ck4 in case it was something else (like BFQ that was just added), but it was the same. It still is the same in ck5.
I have not noticed anything else going wrong since ck2, but I haven't tried playing native games since then.
I'm not sure how to give better information.
Try recording the output of top continuously with
Delete'top -Hb > toplog.txt' until the freeze happens and then send me the output of it via email.
@ck and all interested testers:
ReplyDeleteCan someone of you explain to me, what it means, when in gkrellm's proc chart there's a severely high continuous amount of "fork" being displayed, along with relatively high sys cpu usage, ~33% on each of 2 cores?
I observe this reproducibly, when firefox loads my set of 160 tabs, after the new changes I added to the kernel:
o MuQSS commits 5065068c and newer applied,
o .config setting to CONFIG_HZ_100=y for the first time instead of 1000 ever before
During this period firefox isn't responding in any way, and only way for relief is playing "switch-to-other-open-windows-game". Or using CONFIG_HZ_1000 again.
My first time to see that, I don't think behaviour is intended to be like that. Side note: In my experience CONFIG_HZ_1000 still leads to a more interactive mouse pointer.
Maybe this info is of help for last debugging steps.
BR and thank you,
Manuel Krause
I still get stutters and system slowdowns when using wine osu! after a period of time.
ReplyDeleteI was able to view the dmesg over the lag and it showed a similar output at during stutter:
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
10月 29 21:18:49 freeiBP kernel: NOHZ: local_softirq_pending 40
Looks like I still haven't killed that softirq problem, whatever it is.
DeleteThanks Con.
ReplyDeleteI've ran the usual tests with MuQSS120 on my laptop.
MuQSS120 shows a little improvement over MuQSS116 indeed.
I don't have any error messages on my side.
The results are here:
https://docs.google.com/spreadsheets/d/1ZfXUfcP2fBpQA6LLb-DP6xyDgPdFYZMwJdE0SQ6y3Xg/edit?usp=sharing
Also, what's the status of interbench ? I plan to setup a test environment next week on my desktop and give interbench and Phoronix Test Suite a go.
Pedro
Hello there. After ck5 and MuQSS 0.120 update GDM and GNOME desktop start had significantly slowed down. This also affects user logout/login/hotchange.
ReplyDeleteVanilla 4.8.4 and 4.8.4-ck4 works pretty good. Any ideas? i5-6600K, GTX960.
If you're getting a slowdown at 100Hz it's worth checking to see if your hardware is not supporting high res timers properly. Look in dmesg and see if there's something like "Could not switch to high resolution". I was hoping they'd be supported on all modern hardware but I could be wrong...
ReplyDeleteJust to reassure "me stupid": Getting HPET or hpet related success lines in dmesg, on the other side, would then mean, HIGH_RES_TIMERS are set into work?
DeleteThis is asked for an ~8 years old Core2duo, without getting failures like you wrote about above.
BR, Manuel Krause
@Con,
ReplyDeleteI tried using mux 120 w/ full tickless enabled. Top shows roughly 50% of each core is busy with "si" except the first "ticking" core (CONFIG_NO_HZ_FULL=y, CONFIG_NO_HZ_FULL_ALL=y), which means software interrupts. That's odd, maybe I messed smth up.
Also, Fedora is doing full tickless quite for some time and it seems ok. What are the downsides using full tickless as You suggest it only for very specific cases? Must be smth with interactivity, but can You please explain that in 2 sentences for "the stupid"?
Br, Eduardo
There is extra overhead when nohz full is enabled, and the first CPU can never shut down ticks when it's idle meaning it actually uses more power than a nohz_idle configuration. If there's something using 50% with soft interrupts (si) then there's actually something wrong too, which is a real possibility.
DeleteFound some missing nohz related softirq code which could be the problem. I'll work on a patch for that today.
ReplyDeleteHi Con,
ReplyDeleteI'm using
zcat /proc/config.gz | grep -i NO_HZ
CONFIG_NO_HZ_COMMON=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
# CONFIG_NO_HZ_FULL_SYSIDLE is not set
CONFIG_NO_HZ=y
# CONFIG_RCU_FAST_NO_HZ is not set
with
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
The mouse pointer and interactivity so far stays fluid and responsive during high load (no audio stalls or glitches AT ALL - up until now),
no high load or stability issues so far
I'll keep you updated
Thanks for the great work !
This is the first time I'm running full dynticks ><'
and I like it :)
For those having softirq issues, either the local_softirq_pending warning with stalls, or high si% count on idle CPUs, can you try the following test patch please?
ReplyDeletemuqss120-try_idle_softirq.patch
This may not be the solution but it will hopefully help me track down what the issue might be.
Or anyone having stalls, wine related freezes or other misbehaviour.
Delete@Con,
DeleteI applied the patch, now it's different:
Tasks: 341 total, 1 running, 340 sleeping, 0 stopped, 0 zombie
%Cpu0 : 12,4 us, 0,9 sy, 0,9 ni, 85,0 id, 0,0 wa, 0,9 hi, 0,0 si, 0,0 st
%Cpu1 : 5,6 us, 0,0 sy, 0,0 ni, 94,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 3,8 us, 2,8 sy, 0,0 ni, 93,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 1,9 us, 1,0 sy, 0,0 ni, 97,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 1,8 us, 0,0 sy, 0,0 ni, 45,7 id, 0,0 wa, 0,0 hi, 52,5 si, 0,0 st
%Cpu5 : 7,3 us, 1,8 sy, 0,0 ni, 90,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 3,3 us, 0,0 sy, 0,0 ni, 47,9 id, 0,0 wa, 0,0 hi, 48,8 si, 0,0 st
%Cpu7 : 1,9 us, 1,9 sy, 0,0 ni, 96,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
It seems now it's way around.
To elaborate: I have changed only 3 options from my default config:
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
CONFIG_RCU_NOCB_CPU_ALL=y
I hope this helps.
Thanks.
Br, Eduardo
@Con,
Deletestrange behavior, after each suspend/resume cycle +1 core have high "si" usage.
This is after 3 cycles:
Tasks: 445 total, 1 running, 444 sleeping, 0 stopped, 0 zombie
%Cpu0 : 8,3 us, 0,9 sy, 0,0 ni, 89,9 id, 0,0 wa, 0,9 hi, 0,0 si, 0,0 st
%Cpu1 : 2,9 us, 0,0 sy, 0,0 ni, 97,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 2,5 us, 0,0 sy, 0,0 ni, 48,5 id, 0,0 wa, 0,0 hi, 49,0 si, 0,0 st
%Cpu3 : 0,5 us, 0,0 sy, 0,0 ni, 50,0 id, 0,0 wa, 0,0 hi, 49,5 si, 0,0 st
%Cpu4 : 1,0 us, 0,0 sy, 0,0 ni, 49,3 id, 0,0 wa, 0,0 hi, 49,8 si, 0,0 st
%Cpu5 : 1,5 us, 0,0 sy, 0,0 ni, 49,0 id, 0,0 wa, 0,0 hi, 49,5 si, 0,0 st
%Cpu6 : 1,0 us, 0,0 sy, 0,0 ni, 49,3 id, 0,0 wa, 0,0 hi, 49,8 si, 0,0 st
%Cpu7 : 3,8 us, 0,0 sy, 0,0 ni, 47,1 id, 0,0 wa, 0,0 hi, 49,0 si, 0,0 st
But no more than 3 cores have high "si" usage even after 5 suspend/resume cycles.
Br, Eduardo
@Con,
Deletenow after even more suspend/resume only one virtual CPU does not have constant "si" usage.
Br, Eduardo
Con, I see no problems in kernel log, neither MuQSS or switching to high resolution. Slowdown actually occurs only on DE/GNOME loading/logout/login, rest system works faster than on vanilla kernel and even than on linux-ck with BFS sched.
ReplyDeleteAh, thanks for elaborating. I'm glad to hear the rest is faster. I have a vague idea what might cause the gnome login slowdown (and slightly slower boot up) and am working on a solution now.
DeleteAlso it's worth to say that MuQSS_try_idle_softirq patch doens't fix this DE login problems. Anyway, thanks for the amazing job, looking forward to new releases!
DeleteI've added a patch to git which *might* help the slow login to gnome.
DeleteHi,
ReplyDeleteI still get this/these BFQ warning(s) once or twice when heavy load occurs near after system startup in graphical target:
[ 53.960106] BFQ WARNING:last 4611686022722359627 budget 13835058059577135366 jiffies 4294971692
[ 53.960110] diff 4611686018427387942
[ 70.537813] BFQ WARNING:last 4611686022722361253 budget 13835058059577137039 jiffies 4294973349
[ 70.537817] diff 4611686018427387926
Generally asked: are these warnings meaningless or is there really a scheduler problem?
Thanks,
Florian.
@Florian:
DeletePlease don't mix this BFS/MuQSS (CPU scheduler) with the other one, the BFQ (disk IO scheduler), what is next door:
https://groups.google.com/forum/?fromgroups=#!forum/bfq-iosched
If I read correctly, there's already a fix for your issue available from their github, mentioned somewhere around the thread "tentative fix of remaining WARNING".
Best regards,
Manuel Krause
Do you mean MuQSS CPU scheduler doesn't work together with BFQ disk IO scheduler? Would it be better to use CFQ or DEADLINE instead? Till now I never had problems using BFS together with BFQ.
DeletePlease follow the BFQ mailing list or the git repo
Deletethese warning should be fixed with latest code:
https://github.com/linusw/linux-bfq/commits/bfq-v8
Or are you still getting them ?
These warnings did appear with actual 4.8.5-3-ck kernel today.
Delete@Florian:
DeleteOMG... this BFQ (IO scheduler) is still hot code. And Con may haven't included latest bugfixes from BFQ into his ck patchset. We've given you links!
The warnings, or better said, messages are harmless, anyways.
MuQSS (former BFS) and BFQ are known to work very well together for years now.
BR, Manuel Krause
By the way: on my Intel Core2 I have a better performance when showing video (Arch Linux mpv player with frame doubling vapoursynth filters running) with around 10% less CPU consumption (~80% CPU instead of 90%) with
ReplyDeleteCONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_HZ_100=y
compared with NO_HZ_IDLE config.
@Florian:
DeleteHave you had tried the CONFIG_HZ_100=y earlier before? I've recently also added the NO_HZ_IDLE=y together with CONFIG_HZ_100, but went back to CONFIG_HZ_1000, what seems to behave better.
But, please, don't omit to read what Con and the others already reported regarding this (above on here). Con said, he's working on a patch.
BR, Manuel Krause
@Anonymous:
DeleteNo, that's the first time I tried CONFIG_HZ_100. I didn't use 1000 Hz but 300 Hz. My conclusion is that 100 Hz indeed is the better choice and performance (responsiveness) is better.
I'm still searching for a solution of lowering CPU consumption when playing video with Linux mpv player and realtime frame doubling via vapoursynth filter. I changed some system values to MuQSS default values as described in the documentation:
kernel.rr_interval = 6
kernel.iso_cpu = 70
kernel.interactive =1
Kernel config:
CONFIG_MNATIVE=y
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
Mpv video player is niced to -15 on Arch Linux and X server has -1.
Are there generally (other) kernel configs to improve performance by lowering CPU consuming for on-the-fly-optimizing video during play on my old but good Intel Core2 Duo respecting MuQSS and BFQ?
My goal is to keep a constantly CPU consuming task (around 80% CPU) stable to not get video stuttering when other processes are still active. I sometimes got stuttering video with "schedtool -I -e mpv" probably because of X server not getting enough CPU.
Thanks a lot,
Florian.
@Florian:
DeleteMy question before is: Why do you at all mean to need to alter kernel .config for using your Core2duo for video playback?
It's working on here (same CPU, on here: laptop shared GPU) very well, mpv via smplayer under KDE. Maybe you'd take a new look on your graphics configuration?
On the fly video optimizing is dependend on the CPU/GPU and further decoding/encoding capabilities. The old Core2duo can even fail with hw/decoding, depending on your MESA version and eventual self-compiled addon drivers.
But in my experience, this is too much you want from that machine.
NORMAL playback is o.k., isn't it, also with previous MuQSS?
BR, Manuel Krause
@Manuel:
DeleteI think we dont' have to discuss the reason for altering my ck-kernel's config. Fact is that in my case of heavy load I get a 10% lower CPU consumption when NOT using the default timer subsystem settings. And that's still my question after Alexander Pavel: does anyone has experiences with altered configs in this special case with MuQSS scheduler in combination with the suggested 100 HZ configuration? I never heard of using CONFIG_HZ_100 before but 1000 Hz or at minimum 300.
Are there other config tweaks or tricks playing well together with ck kernel, MuQSS and BFQ?
@Florian:
DeletePrevious advice for BFS for years now, was set CONFIG_HZ_1000, now, other available CONFIG options are possible firstly since MuQSS v0.120.
Con actually also advertised the NO_HZ_IDLE, what doesn't harm vs. CONFIG_HZ_PERIODIC on here.
Further things:
Search this blog for "kernelOfTruth", he provided very useful base information regarding low-latency, being still valid.
BR, Manuel Krause
@Florian - configuration changes can only do so much - there is only so much CPU power for you to use and you shouldn't be able to decrease its usage further significantly. However if you are running mpv sched iso, you can push up the sched iso limit to higher like 90%.
Deleteecho 90 > /proc/sys/kernel/iso_cpu
I've pushed an updated patch for dealing with softirqs to git. Use that instead of the patch I put into the test directory I linked earlier.
ReplyDelete@Con,
ReplyDeleteI applied both patches and still have the same high "si" usage in top command. Apart from showing strange "si" usage values, normal system behavior is not really affected, as far as I can tell.
Also, it appears that I don't have to suspend/resume for more CPU's to start having high "si" usage, they start doing it by themselves after some time. I don't know what triggers it. At boot it's 3 CPUs with high "si", later up to 7. Weird.
I'll keep using this kernel for some time and see what happens.
Br, Eduardo
Thanks Eduardo. I suspect it's just an accounting bug to do with you running full nohz and is actually not doing anything harmful. Will look into it at some stage. The softirqs patch is more for those who get the local_softirq_pending warning and associated stalls.
Delete@ck,
ReplyDeleteI've tried to build linux-ck with 2 new commit fixes (just to test), but Gnome login hasn't speeded up.
I compared CONFIG_HZ_100 with CONFIG_HZ_1000 (without test patches) and new defaulting 100 HZ boots faster and more "fluid" on my old Core2 Duo machine, system has better responsiveness and less waiting till graphical userspace is ready. I have no data to prove this but as I know my system very well and never had configured with 100 HZ before - thumbs up!
ReplyDelete@Florian:
DeleteNice to read, that you've tested this comparison on your machine too.
I personally don't care much about startup behaviour (when successful ;-) ), but more for interactiveness when the DE is up.
With the CONFIG_HZ_100, what I assume, you'd prefer to use now, do you experience more or longer mouse pointer lags than with 1000? I do, and that's the reason for me to still prefer 1000.
May I ask you to name your DE and gfx driver(s) in use? Does your Core2duo also not support HT/SMT (like mine)?
Thank you in advance and BR,
Manuel Krause
@Manuel:
DeleteI did not notice any mouse pointer lags with CONFIG_HZ_100, I only noticed them when starting mpv with "schedtool -I -e mpv" and then changed from fullscreen to normal window, but in this special case that seems to be normal. Mouse pointer lags (that are indeed very bad) are completely unknown for me with my Core2 Duo. My comparison is subjective but as I'm very critical concerning my system's behavior I notice that some lags during CPU intensive states are shorter meaning my system is more fluid. Sorry for my English not being my mother language! In other words: it seems that my older hardware prefers not to be interrupted too often. ;-)
I don't know if my Core2 Duo supports HT/SMT, I deactivated SMT in all my kernel configs as I read it wouldn't be necessary.
How do I display gfx driver(s) in use? DE? I use openbox.
@Florian:
DeleteNo need to bother with quality of native language speaking. On here, there are so many nations present, and you are writing readable.
With "DE" I meant 'desktop environment' and you answered with "openbox", what is absolutely unknown to me, so far. I've needed to wikipedia for it ;-). I'm having KDE on here with an older openSUSE distro, keeping it continuously updated, btw.
For the graphics' kernel module/driver you can ask "lspci -v" in a console and look for the keywords, or find something with "dmesg | grep drm" and/or reading dmesg output around these lines. Regarding the Xorg gfx driver you'd take a look on /var/log/Xorg.0.log. This is only for your information.
My testing results are also only based on subjective observations so far, I'm also very critically watching any changes from the status quo before, just like you do it. As I don't know openbox from own experience and don't want to switch away from KDE, it may be, that our comparisons remain uncomparable.
Regarding your fullscreen/windowed display switching topic, it's lagging on here too, but has not much to do with the cpu scheduler - more with the gfx driver from the Xorg side.
Regarding the Hyperthreading capabilities, you may want to search the Intel site for your own cpu. Although each of my two cores ship the "ht" flag in /proc/cpuinfo, they won't do it, tells Intel.
BR, Manuel Krause
@ Manuel:
DeleteI used xfce4 before but Openbox has fantastic configuration capabilities like hotkeys for windows resizing, you can config all that you want and Openbox is still very thin (compared with Gnome, Mate etc.).
I'm on Arch Linux for 3 years now after Suse and Linux Mint. Arch is great for learning with Linux and as rolling release distro I had no reinstallation ever.
Since I compile my own kernels for about 1 year now with only modprobed modules and mostly 100% configured for my hardware I have got a multimedia machine most users are dreaming of. As already told besides mythtv (with vdpau) and alsa configuration with plugins (equalizer, expander and limiter for optimizing speech in videos in realtime) I now have a nearly perfect video quality (some filters in chain for optimizing colors and ringing artefacts etc.) of youtube videos at 50 fps (of course monitor too), absolutely fluid inspite of frame doubling on-the-fly with 80% CPU, but stable without big A/V desync and with great sound.
Some hardware data:
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized nvidia-drm 0.0.0 20150116 for 0000:01:00.0 on minor 0
VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GT] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Point of View BV Device 8582
[...]
Kernel driver in use: nvidia
Kernel modules: nvidia
And there is the nvidia_uvm module when using GPU based video transforming via opencl-nvidia-340xx (OpenCL implemention for NVIDIA). You see I use the proprietary driver and the dkms module (nvidia-340xx-dkms), fantastic when having 5 different kernels.
Thanks for your explanations and help,
Florian.
@Florian:
DeleteThat's quite nice to read about your fine gfx hw on an old core2duo.
It can be, that you don't use the most actual proprietary driver from NVIDIA atm., what you should give a try too.
As you are familiar to kernel building, you'd also be able to recompile the proprietary nvidia module, if asked for. Have you already fetched the most recent NVIDIA "blob" and given it a try?
BR, Manuel Krause
@Manuel:
DeleteI assume that this isn't the most actual proprietary driver as my GeForce 8800 GT is legacy about 1 year. Since this time I'm getting angry about reading about 30-40 times
NVRM: nvidia_frontend_ioctl: minor 255, module->ioctl failed, error -22
after reaching Openbox without any viewed issues. What I do is to compile the kernel dkms module by myself but there won't be a difference to a pre-compiled one.
That sounds interesting what you are writing! I have no clue how to do that. What's the most recent NVIDIA "blob" and how can I compile the module by myself?
Florian
Hey Florian,
DeleteHave you built the nvidia-340xx-ck driver from AUR, to use with linux-ck (and then re- mkinitcpio after installing both)?
aur.archlinux.org/packages/nvidia-340xx-ck/
I used to use the (latest) proprietary driver with a GT430, but after changing a bunch of hardware (GTX275, legacy 340xx driver) and fighting to get everything setup, I got fed up w/ the no-high-res-console and switched back to nouveau.
Hey jwh7,
Deleteno, I have nvidia-340xx-dkms installed (or self-compiled from ABS) after I realized that this is much easier when recompiling because I have 4-5 different kernels. There is a hook in dkms so that nvidia automatically recompiles after updating one kernel, that's excellent.
Are you lucky with nouveau? I tested it for some minutes and quality is... I couldn't use it for my mpv player, much more CPU consumption etc.
The console indeed is poor, I was fighting there a little bit but now have found one vga option that allows me to scroll back to top when booting before logging in to graphical userspace.
@Florian:
Delete"blob" is another name for a (maybe huge disk volume consuming) proprietary driver setup. Like ATI/AMD/NVIDIA are known for.
You can fetch the installer on your own from their site and follow the instructions, what would hopefully install your individual gfx module. I assume that you know how to download from the nvidia site.
Keep your disk backups uptodate, as always recommended, I'm not responsible for possible misbehaving.
BR, Manuel Krause
@Manuel:
DeleteI did this years ago but it doesn't make any sense: download target of NVIDIA drivers are the same, Arch distro packages do the same via script inside package manager (pacman). If I download and install driver with NVIDIA shellscript by myself, I have no chance to keep track of this installation via pacman. It's not advised and doesn't make any difference.
I thought you would mention another unusual way to get rid of these legacy drivers. I just tested it once more and I get the standard 67 MB installation file NVIDIA-Linux-x86_64-340.98.run for download and installation for my NVIDIA GeForce 8800 GT. Exactly this do package manager scripts in background.
Florian
I know it's very subjective what I write but as I'm new to linux-ck kernel since a few days and just upgraded to 4.8.6-1: seems to be an EXCELLENT work, dear CK! :-)
ReplyDeleteThe 100 HZ work absolutely fine on my 8 years old Core2 Duo machine and even sound quality improved a little bit! I have to explain that I'm an audio freak meaning I mostly hear my music by headphone. I resample my audio via own alsa config doubling samplerate to 96000 before it passes Eq10 equalizer. So I know how excellent my music sounds and I just realized that with this kernel it's even better, absolutely precise, clear and fantastic! I don't know if it's the 100 Hz (never configured my kernels before with that freq), MuQSS or the kernel itself, but compared to Liquorix or Zen kernel I'm aware of further giant steps directly to perfection! Thanks for this brilliant work! :-)
Florian
Do yourself a favor a get a Xonar soundcard - you'll immediately notice the difference in sound output ;)
Delete(take a look to make sure you pick up a "good" model with 192 kHz support which is fully supported under linux)
@kernelOfTruth:
DeleteThanks! I read that you gave some good advises how to optimize kernel building by changing some config options. Could you please give me a hint where you posted this in the past or would you mind to post them here? 100 HZ is great, disabling NUMA was new to me, I modprobed all my modules and my kernel's build time on my old Core2 Duo is about 12 minutes in comparison to about 70 minutes. It seems to be good for me to select CONFIG_HZ_PERIODIC and beside maybe compiling my own nvidia kernel module perhaps I'm able to even more optimize my kernel.
Thanks in advance,
Florian.
http://ck-hack.blogspot.com/2016/10/linux-48-ck5-muqss-version-0120.html?showComment=1477778598380#c8694377182197010404
Deletejust search for the name, chromium/chrome's highlight functionality is excellent as it shows all the occurrences at once at the scroll bar at the right ;)
not sure what else options - my "oldest" system right now is an IvyBridge based laptop so I can't give much advice how to tweak towards that kind of hardware (which might require different kind of tweaking compared to the newer Intel or AMD processors)
@ck:
ReplyDeleteMaybe it's a little too much wishful thinking of mine, that you still also maintain the 4.7-muqss git branch after 4.7 got tagged EOL. I just tried to compile with the newest 3 commits upon v0.120 on 4.7.10 and it failed with the following abort message:
...
CC kernel/time/timer.o
CC arch/x86/kernel/cpu/mtrr/generic.o
kernel/time/timer.c:1328:42: warning: ‘struct timer_base’ declared inside parameter list
static u64 cmp_next_hrtimer_event(struct timer_base *base, u64 basem, u64 expires)
^
kernel/time/timer.c:1328:42: warning: its scope is only this definition or declaration, which is probably not what you want
kernel/time/timer.c: In function ‘cmp_next_hrtimer_event’:
kernel/time/timer.c:1347:7: error: dereferencing pointer to incomplete type
base->is_idle = false;
^
kernel/time/timer.c: In function ‘get_next_timer_interrupt’:
kernel/time/timer.c:1393:32: warning: passing argument 1 of ‘cmp_next_hrtimer_event’ from incompatible pointer type
return cmp_next_hrtimer_event(base, basem, expires);
^
kernel/time/timer.c:1328:12: note: expected ‘struct timer_base *’ but argument is of type ‘struct tvec_base *’
static u64 cmp_next_hrtimer_event(struct timer_base *base, u64 basem, u64 expires)
^
make[2]: *** [kernel/time/timer.o] Error 1
make[1]: *** [kernel/time] Error 2
make: *** [kernel] Error 2
make: *** Waiting for unfinished jobs....
CC arch/x86/mm/init.o
...
I hope, it's readable on this blog... and you can give me a hint on how to fix it.
Thank you in advance,
BR, Manuel Krause
It's gotten "edited" too much by the blog's interface.
DeleteHere's a more readable one: http://pastebin.com/1hiFEnbb
BR, Manuel Krause
@ck:
DeleteNothing good for me in this case? Just wanted to make up two last known good 4.7.10 muqsss kernels with 1000 vs. 100 Hz.
Thanks in advance & BR
Manuel Krause
@ck:
DeleteWow... You're still pushing out patches, now also modifying external drivers? Brave man! :-)
And a huge "Thank you!" for fixing the 4.7 build issue (by commit )!
I've also been using 4.8+, but I'm still not ready with my try to port old TOI to 4.8, unfortunately.
Regarding my previous reported resume warnings: They appear to be timing related, like I also had experienced at birth of Alfred's VRQ. With a lockup, the dmesg of it gets readable, if not not. With the v0.120 on kernel 4.7.10 I've had over 5+ days of uptime and more than 13 successful resumes from TOI hibernation.
BR, and thank you for your work,
Manuel Krause
above left out commit no. is 660ebad for 4.7 muqss only kernels
DeleteThis comment has been removed by the author.
ReplyDeleteHello again, Con!
ReplyDeleteI've built linux-ck with all latest commits (including 6a764ab) to test and found that 6a764ab did some speedup on DE loading/login/relogin, but even in this case vanilla upstream kernel is faster on this actions than ck5 with MuQSS (on my Skylake machine).
Best regards.
@VV To which commit do you refer? I don't see 6a764ab; latest is da7832b*01e00ff.
Delete@Vincent Vega:
DeleteAlso with the 4.7 branch I can't pin down your mentioned commit. Please check again on your side, and then complain on the right site!
BR, Manuel Krause
@VV the last change was related to working at low Hz. Are you comparing 100Hz MuQSS with kernels running other Hz values? If so, then it would be interesting to compare the same Hz on different kernels. If the gnome login is Hz dependent, then that's quite sad and suggests some inefficient design implementations.
DeleteFor completeness, and to answer my own question...6a764ab is on the 4.8-ck branch, which I didn't realize existed now. I looked at the -muqss branches. Con, I presume -ck is now the official repo, while -muqss is more for testing?
DeleteThe -ck branch is what goes into the -ck release (which is a few extra patches and the -ck branding) while the muqss branch is muqss only, so -ck branch has more changes in it than the muqss branch does, though the muqss version in both is the same.
DeleteThis comment has been removed by the author.
DeleteFirst of all thank you very much.
ReplyDeleteI have been using old kernels like 3.12... because of speed and responsiveness (with bfs and bfq) and shunning the 4.x kernels but this one (4.8 muqss git+bfq) is just as fast if not slightly better in some areas.
I play Xonotix open source game occasionally and I noticed a maybe 0.5-1 sec freeze/hang for maybe 3 times in 2 hrs.
Apart from that pretty solid on my test machine.
Keep up the good work.
*Xonotic, my bad
Deletethis might be because of BFQ
DeleteBFQ is known to equalise disk load. not overloading cpus and disks but providing max. possible throughput...
DeleteYou can change the disk scheduler at any time to your preference by issuing a command to your disk(s).
BR, Manuel Krause
Some "great" news to the GNOME users.
ReplyDeleteCon, you're completely right, GDM and part of gnome-session (or gnome-shell) has some Hz-dependent function realizations. Because:
vanilla linux 4.8.6 with 300 Hz timer - login and DE loading is fast.
vanilla linux 4.8.6 with 100 Hz timer - login and DE loading is VERY slow.
linux-ck 4.8.6 (MuQSS 0.120) with 100 Hz timer - login and DE loading is slow.
linux-ck 4.8.6 (MuQSS 0.120) with 1000 Hz timer - login and DE loading is fast.
linux-ck 4.8.4 (BFS 0.512) with 1000 Hz timer - login and DE loading is fast (a bit slower than with MuQSS).
So I think it's a good reason to open new issue in upstream GNOME bugtracker.
Thanks very much for confirming that. I suspected that was the case based on your earlier feedback which rules out a muqss bug. This definitely should be reported as a gnome bug.
Delete@Vincent Vega
DeleteOn my side I've no problems with 'MuQSS120 + 3 patches in git' with 100Hz timer, Gdm + Gnome 3.22 and intel graphics driver (on Archlinux).
What version of Gnome do you use ?
Pedro
@Anon
DeleteGnome 3.22.1 on Arch Linux. But I have NVIDIA card, GTX960, and use its official proprietary drivers. I'll test this issue on Nouveau open drivers later and report here (possibly it's even Nvidia bug?).
The same slowdowns with Nouveau driver, on both X and Wayland sessions. Seems like it's certainly Gnome issue.
DeleteCon, thanks for help with this problem and for linux-ck!
@Vincent Vega:
DeleteIt may be sad for you atm. but I want to thank you to track this down so deeply!
I'm not at Gnome, but any user benefits of your encouraging activity.
Thank you, BR, Manuel Krause
Just wanted to mention, that I've not noticed any slowdowns on Gnome 3.22.1 startup after switching to 100Hz either (also using Arch Linux, and linux-ck-nehalem-4.8.6-1 from greysky's repo). Although I'm running rather minimal gnome install, without pulseaudio, GDM and some other stuff. Also, I'm using radeon mesa drivers.
DeleteMy sandy bridge laptop, with intel graphics and pretty much the same gnome setup also seems to start in decent time.
I'd suggest if disabling pulseaudio of gdm helps. you could also try the modesetting driver to rule out graphics drivers causing your issue.
Linux 4.8 w MuQSS 4c59753
ReplyDeleteSystem stutter and freeze (only SysRQ could be used to shutdown) when Wine is running or when JACK is running after TLP had set switched to battery mode
Dmesg messages:
[ 650.039583] NOHZ: local_softirq_pending 202
[ 670.112980] NOHZ: local_softirq_pending 02
[ 720.029885] NOHZ: local_softirq_pending 202
[ 870.242973] NOHZ: local_softirq_pending 202
[ 1025.751366] NOHZ: local_softirq_pending 202
[ 1025.761367] NOHZ: local_softirq_pending 202
[ 1030.641595] NOHZ: local_softirq_pending 202
Thanks for that. It confirms that I need to approach that problem even more aggressively than I currently do, so it's good that I held off making a new release.
Delete