I will try those settings on 3.6.2. 3.5.7-r1 seems to be working with the same config. I'm running JACK and will leave it running for a while as a test. If there are no xruns while I'm doing a bunch of stuff on the machine, WIN!

The only thing I notice, using 3.5.7-r1, is that switching to this machine on my hardware KVM switch takes longer than it does with any other kernel, bar none. I have to wait a few seconds for the keyboard to start working. It's almost instantaneous with other kernels using the exact same config.

Please note as stated in the OP that if you boot on KVM with 3.6.2 you *want* to set the kvm useflag._________________

I have a little box to switch my keyboard and mouse between two computers. Not Kernel Virtual Machine.

Still a lag of seconds when switching back to this machine. What could cause that? Must be something in the patches specific to ck-sources.

I just made and tested those changes you suggested earlier. I'm running with the freq at 10kHz. Nothing bad has happened yet. What are the advantages of running at speeds greater than 1000? 1000 Needs to be the minimum for audio production, wondering why there are faster speeds here.

So there's really no actual advantage to setting the frequency to 1500 or 5000 Hz, even for audio production?

Hrmmm... the short answer is : There is really no actual (or is it actually no real...) advantage to setting the frequency to such high values for who knows what he his doing and controls what he his doing accordingly.

If we keep RT-processes apart (they are managed specifically by the scheduler) and pay attention to more ordinary processes which can be either IO-bound (heavy use of I/O devices and most of the time spent waiting for I/O operations to complete) or CPU-bound (requiring a lot of CPU time).
The scheduler, which constantly monitors the cpu spent by the tasks, will quickly penalize the CPU-bound tasks by automatically lowering their priority.
Therefore I/O-bound tasks will quickly preempt the batch processes, no matter how long the time-slice is.

However, if you do not pay any particular attention to scheduling models or priorities you can fall into a trap : The scheduler does not know a-priori if the process you launch is a batch process or an interactive process. It needs some times to discover this by itself...
Which means that if you launch concurrently one CPU-bound process and one interactive process, the interactive process might have to wait for a whole time-slice before starting its execution.
Of course, processes which are sometimes CPU-bound, some other times I/O-bound will delay other processes similarly each time they change their behavior from io/bound to cpu crunchers.

As a consequence of this, if you don't want to care with RT-PRIOS and scheduling models && emerge -e world BUT imperatively need whatever program to be started in less than a millisecond... then you should consider increasing the timer frequency over 1000Hz. (Of course, because of task switching, the overhead will be increased)

Of course, wise users will first help the scheduler by increasing its knowledge a-priori, that is to say that they will nice -n 19 their makes, run SCHED_IDLEPRIO what they do not really care about and SCHED_ISO their favourite audio apps._________________

then you should consider increasing the timer frequency over 1000Hz. (Of course, because of task switching, the overhead will be increased)

because of this overhead I decreased to 300 Hz and disabled NO_HZ. Think of 300 times in one single second the cpu gets a heavy IRQ event to reschedule (therefore stoping all other work). This is enough!

Though I don't know if you in favor of less power consumption -mobile reason- enable NO_HZ ..._________________fun2gen2

I think I understand that. Linux audio systems are supposed to have programs started by certain groups, such as the realtime and audio groups, given the correct scheduling priority anyway via limits.conf. So it's not so important that a program start quickly so much as it is given priority. I guess that would mean 1kHz should be sufficient and higher frequencies might be overkill for audio production.

You need a keyboard-video-mouse switch. No particular anything running. It just takes several seconds for the keyboard and mouse to be grabbed when I switch back to my DAW when it's using ck-sources. I figure there must be something different in the patches because this has happened with NO other kernel I've ever used. Since my switch is USB, I would assume it has something to do with USB in the kernel patches (not the config, which works just fine in other kernels I use)._________________Gentoo Studio: http://gentoostudio.org
Facebook: http://www.facebook.com/gentoostudio
G+: https://plus.google.com/113947758237122861689/posts
Pappy's Kernel Seeds: http://kernel-seeds.org

You need a keyboard-video-mouse switch. No particular anything running. It just takes several seconds for the keyboard and mouse to be grabbed when I switch back to my DAW when it's using ck-sources. I figure there must be something different in the patches because this has happened with NO other kernel I've ever used. Since my switch is USB, I would assume it has something to do with USB in the kernel patches (not the config, which works just fine in other kernels I use).

I don't get such device.
Do you get other troubles with other usb devices in general ?
Can you post the lines of your kernel log related to the attachment of this (I presume HID) device by its driver. Something looking like this :

On a side note, the .config you posted earlier says : CONFIG_USB_SUSPEND=y
Do you actually need that ?

No, actually, but the problem persists when I turn that off.

I also just noticed that I had to manually shut the machine off with user "halt" in my login manager. I don't remember doing that before, so is it possible that CONFIG_USB_SUSPEND has any affect on that?

Earlier in this thread, I mentioned switching between two machines with a hardware KVM switch being slow when using ck-sources.
Well, it's clearly not the ck patches. It looks like something in the kernel itself, because I have the same problem when using the latest 3.6 rt-sources. Maybe I should file a kernel bug...

I cannot tell if this might account for such an important delay but I have read somewhere an user reporting similar troubles that he had found directly linked with the dynticks feature.
If you built your system tickless, maybe you can try booting after appending nohz=off to your boot command line in order to test if things are better.

And, BTW, can you post the lines of your kernel log related to the attachment of the (I presume HID) device by its driver ?_________________

Following Bug 447718 - and thanks to Markos Chandras, 3.6.11 is out.
It will be the last release of the 3.6 branch and all users of 3.5.7 or 3.6.2 should upgrade. It is actually worth it._________________

Following Bug 458874 - and thanks to Markos Chandras, 3.4.32 is out as latest release of the long term stable branch.
All 3.4 users should upgrade.

Per same bug, 3.7.9 is out too but... about it... no wise user, I mean no user using the ck-sources<3.7.9 for work, is invited to "upgrade".

BTW, with the 3.7.9 a patch is being applied on the "legacy" bfs-426, fixing a couple of bugs. (corner cases)
If those bugs are impacting on 3.4.x or 3.6.11 users, I'll make my best to port this patch to these releases.
Just tell._________________

Con Kolivas not only has adapted the BrainFuckScheduler to Linux-3.8 but also made at least two corrections to time accounting. Which I previously grumbled about at his blog, because as a simple user not able to handle the perf infrastructure I feel dependend on such tools as top to audit my own system.

Con also erased two of his ck1 patches:
mm-decrease_default_dirty_ratio-1.patch
mm-minimal_swappiness.patch

Which he thinks should be handled by distributions charge of sysctl. Surely these patches were based on old assumptions not any more true, because of such newer things as HugePages, especially when running virtual machines.

I think applying Cons hz-default_1000.patch is good for gamers.
But pure office users and developers, who often call gcc to compile,
reach better throughput by options like:

Code:

CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=88
# CONFIG_NO_HZ is not set
CONFIG_HZ_300=y
CONFIG_HZ=300

@aCOSwt, and there is a new Linux-3.8.2 Bfs which runs perfectly well:

I am currently testing it and, if successful, I'll push a 3.8.3

ulenrich wrote:

Con Kolivas not only has adapted the BrainFuckScheduler to Linux-3.8 but also made at least two corrections to time accounting.

You are correct but these corrections have been made in bfs-427.
Early 3.7 were patched with 426 but I ship the 3.7.10 of the ck-sources with 427. => The ck-sources-3.7.10 users already enjoy these corrections you mention.

ulenrich wrote:

Con also erased two of his ck1 patches:
mm-decrease_default_dirty_ratio-1.patch... Which he thinks should be handled by distributions charge of sysctl. Surely these patches were based on old assumptions not any more true, because of such newer things as HugePages, especially when running virtual machines.

As for the dirty-ratios, not exactly.
Con removed the setting of the defaults following a discussion I had with him on IRC demonstrating that just "plenty" of programs were arbitrarily "playing" with the dirty-ratios from boot time, rendering vain the action of this particular patch._________________

Eric, for what it's worth, I've been running the 3.8.2-ck as well and it looks quite fine from where I sit

I think your plan is good, test it for a week or so more, then release a 3.8* to everyone, with the bfs-427, which is really important. TBH, I skipped over the 3.7.x versions on my boxen waiting for the next major update. [I would think that many others did, as well.]