# ck-sources : All about choice !

## aCOSwt

Gentoo is all about choice, so are ck-sources!

Having slept a little, the ck-sources project comes back with new features and new opportunities.

I/ NEW FEATURES

Starting from revision 7 on the 3.5 branch and from the version that will follow 3.4.9 on the 3.4 branch, users will get a couple of opportunities to tune the patching of their kernel via new useflags.

I.1/ bfsonly

Con Kolivas patchsets include the Brain Fuck Scheduler and several other patches designed to increase the system's responsiveness. Of course, any user willing to obtain the lowest possible latency whatever the expenses (i.e., Digital Audio Workstations, Near-To-Real-Time process supervision...) wants the full ck-patchset to be applied and won't set this useflag. This is as the ck-sources always did and this is the default behavior.

This useflag is intended for those who only want to change their default CFS scheduler to BFS. No other patch from the patchset will be applied.

This opportunity might satisfy anyone looking for a general purpose desktop with a better interactivity/responsiveness than what is achievable under a stock kernel but not necessarily sacrificing everything; and in particular, IO throughput, for the sole sake of latency. If all you want is to run some consumer grade multimedia application or game while compiling or rsyncing, try setting this use flag.

I.2/ experimental [From 3.4 to 3.7]

Con Kolivas develops other patches, mainly dedicated to the testing and development of new ideas. This experimental useflag does nothing by itself apart from authorizing the ebuild to take other useflags into account. However, because all the other useflags will actually trigger the commit of highly experimental code (that is to say code that might significantly reduce the performances of the kernel and even break it) we strongly discourage anybody wishing to run a stable kernel to set it. Only users carefully following the status of these patches, involved in their development/testing, or just wanting to have fun should set it.

I.3/ urwlocks [From 3.4 to 3.7]

This useflag will, if the experimental useflag is set, modify the global runqueue of BFS in order to use upgradeable read/write locks instead of the grq spinlock. If you do not know what this means, do not set this useflag.

The current status for this patch is : No demonstrable impact on performances.

I.4/ kvm [3.6]

Kernels of the 3.6 branch will not boot on kvm unless this useflag is set.

Be aware that setting this use flag might cause troubles if the voluntary preemption model is chosen. (CONFIG_PREEMPT_VOLUNTARY=y)

I.5/ deblob

2.6.38-r3 was the last release honoring the deblob useflag. The tree has been made compliant with the freedist license under which the ck-sources are distributed, this enabling any available version to be installed free of... non-free code.

I.6/ In conclusion:

-If you want the ck-sources as usual, want the lowest possible latency whatever the expenses for some near-to-realtime professional purpose: emerge -bfsonly -experimental -urwlocks 

-If you want a highly interactive, general purpose desktop running consumer-grade applications: emerge with bfsonly

-If you want to have fun with the bleeding edge, or participate in the development and testing of new concepts, then: emerge with experimental urwlocks

-You intend to boot on kvm? Emerge with kvm!

-You want to free your Gentoo? Emerge with deblob!

II/ NEW RELEASE POLICY

II.1/ No confusing version numbers

All ck-sources packages will be released under the version string used by the gentoo-sources package it is based on.

eg: ck-sources-3.4.9 are based on gentoo-sources-3.4.9

II.2/ Early revision

Some users of the ck-sources are indeed willing to stay on the highest possible version number. For their benefit we will try to go on providing an early release for each new branch. Except in very unusual circumstances, one can reasonably expect the first release of a given branch to be pushed into the tree a week or so after the release of gentoo-sources-V.B.3.

II.3/ Stable-Like revisions

We also want to welcome Gentoo beginners, those of us who wisely maintain their system updated to the last stable version of each package and scrupulously follow the widespread advice not to mix arch and ~arch on their system. For them, we will also do our best to provide on each branch, at least one stable-like version based on the first gentoo-sources stable release available on this branch.

By stable-like, we mean a release that would inherit the qualities of a gentoo-sources stable release, amongst which is the possibility to build it with a stable tool-chain and the aptitude of the resulting kernel to fit perfectly with full stable arches, including in particular the compatibility with stable proprietary drivers. This version will have been previously tested and benchmarked under a stable system.

II.4/ Long Term Support revisions

We also get pro users - users who need their system to work reliably on long term projects and cannot afford the hassle of a kernel version change/qualification for quite long periods of time. For them, we will follow the last long term support branch as far as possible.

II.5/ In short today:

- You want the ck-sources as usual for fun, testing highest possible version numbers even if they are not the best performing kernels? emerge =ck-sources-3.13.5

- You want the last stable-like release? emerge =ck-sources-3.10.32

- You want the long term support branch? emerge =ck-sources-3.10.32

III SPECIAL THANKS TO:

- Markos Chandras,

- thunderrd.

----------

## audiodef

I'm going to try this out on my laptop.   :Smile: 

----------

## aCOSwt

 *audiodef wrote:*   

> I'm going to try this out on my laptop.  

 

You are welcome audiodef !

Then I suggest 3.4.9 or 3.5.7 +bfsonly

Go with CONFIG_NO_HZ=y 

And do not hesitate to CONFIG_HZ=300 if you need to preserve battery life, results will be better than CONFIG_HZ=1000 with CFS anyway.

And... do not forget : MAKEOPTS="-jX" with X exactly equal to the number of cores.

BFS does not need to be overfed to be efficient.

Anyway... Enjoy and... if the ck-sources can help you augmenting http://audiodef.com/albums.php, I'll be happy !

----------

## audiodef

 *aCOSwt wrote:*   

> 
> 
> Anyway... Enjoy and... if the ck-sources can help you augmenting http://audiodef.com/albums.php, I'll be happy !

 

 :Smile: 

I do that on a different machine, using rt-sources. Do you think ck-sources has any latency advantage over rt-sources?

----------

## aCOSwt

 *audiodef wrote:*   

> Do you think ck-sources has any latency advantage over rt-sources?

 

Of course not ! AND Of course yes !

 :Confused: 

Of course not : Well, these two packages do not really play in the same league. 

Thanks to rt-sources, you may expect latencies in the µs magnitude, with ck-sources, you will get overall latencies in the ms range.

Oh wait !

Of course yes : The considerable latency advantage ck-sources get over rt-sources is that... it comes free of extra charges, automagically. You do not get anything to do at all, nothing special to configure, no specifically designed application to run, no specific hardware to have... Make your kernel, install it, boot and fire whatever audio / video app / garland of jack-aware apps... you will obtain an overall latency under the limits of your human capabilities.

Set appropriate priorities, you can even fire a compilation in the background without any impact in terms of Xruns.

Under rt-sources, nothing like this will happen ! If the applications you run under this kernel have not been specifically designed for, that is to say following the art of real-time programming, you are likely to obtain results even worse than under a stock kernel. There are in portage a couple of apps that, if running under an rt-source kernel, will happily transform your 8 cores box into a single task system. Well... I exagerate a little : Into a voluntary preempt system. Well... something like Windows-98...   :Very Happy: 

(BTW : jackd likes real-time priorities but... would indeed get fired into a true real time environment. (Jackd merely passes its time polling file descriptors and polling is evil in a real time context))

For the same reason that polling is something striclty prohibited in true real-time environments, you also need very specific (and generally very expensive) hardware.

All this makes so the rt-sources are more generally found in embedded systems running some process supervision / driving bespoke.

As a conclusion of this, you have a process in which some tasks sometimes need to be granted all the ressources of your system in a couple of µs to the full expense of everything else, then program it and run under rt-sources. In this context, ck-sources would be nothing but a joke. The ck-sources are not a true real-time operating system.

You run on the shelve apps in a desktop environment ? Opt for the ck-sources.

In such a context, rt-sources won't be capable of helping whatever. You'll globally slow down your system (Because the true real time capabilities of the rt-sources imply a significant overhead) and if a single of your apps running is buggy then... you can plug your system off !

(I experienced once some trouble with jackd under the rt-sources... I could not even type kill -9...   :Rolling Eyes:   )

----------

## PaulBredbury

Note that threadirqs works with a non-RT kernel, these days - worth a try.

----------

## aCOSwt

 *PaulBredbury wrote:*   

> Note that threadirqs works with a non-RT kernel, these days - worth a try.

 

 *PaulBredbury wrote:*   

> # For a non-RT kernel, use kernel option: threadirqs

 

 :Confused: 

You are certainly correct underlining the advantages of threaded irqs but, as far as I understand on an x86 arch, CONFIG_IRQ_FORCED_THREADING is not an option. I mean neither something you can select or not, nor something you need to specifically activate via some boot option.

----------

## PaulBredbury

Evidence, on 32-bit x86 with PAE:

```
$ zgrep THREADING /proc/config.gz 

CONFIG_IRQ_FORCED_THREADING=y
```

```
$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r | head -n 10

     -  TS 23527  33   0 grep --color=auto FF

    99  FF     8 139   - [rcun/0]

    90  FF    67 130   - [irq/8-rtc0]

    74  FF 26231 114   - [irq/49-nvidia]

    72  FF   276 112   - [irq/46-snd_hda_]

    70  FF    59 110   - [irq/19-uhci_hcd]

    60  FF    64 100   - [irq/1-i8042]

    60  FF    63 100   - [irq/12-i8042]

    52  FF   681  92   - [irq/47-eth0]

    50  FF    61  90   - [irq/18-uhci_hcd]
```

Those rtprio values are only visible & settable with the threadirqs boot-commandline option.

----------

## audiodef

If those are indeed the advantage of ck-sources over rt-sources as applied to audio production, I'm definitely going to have to check it out and possibly include it as the recommended kernel for Gentoo Studio instead of rt-sources. I already know that for audio production, low latency in ms in a must, but low latency in µs is technically overkill. With all the overhead you say rt-sources has, ck-sources sounds like a better deal.  

Will let you know how it goes when I try it out.   :Smile: 

----------

## aCOSwt

 *PaulBredbury wrote:*   

> Evidence, on 32-bit x86 with PAE:
> 
> ```
> $ zgrep THREADING /proc/config.gz 
> 
> ...

 

Well... I did not say that CONFIG_IRQ_FORCED_THREADING does not exist. I did say that it is *not* a selectable option.

```
Symbol: IRQ_FORCED_THREADING [=y]

Type  : boolean

Selected by: X86 [=y]
```

Which means that irq handlers are threaded without any need to select / configure / set anything particular.

 *PaulBredbury wrote:*   

> 
> 
> ```
> $ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r | head -n 10
> 
> ...

 

Under my 3.5.7-ck, I do not set threadirqs in my boot-commandline and I can read

```

acoswt@PrimaPratica ~ $ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r | head -n 10

   100  FF    10 140   - [migration/1]

   100  FF     6 140   - [migration/0]

    99  FF  2194 139   - /usr/bin/jackd -P89 -m -dalsa -dhw:3 -r44100 -p256 -n3 -Xseq -P -zs

    99  FF     8 139   - [rcun/0]

    89  FF  2194 129   - /usr/bin/jackd -P89 -m -dalsa -dhw:3 -r44100 -p256 -n3 -Xseq -P -zs

    84  FF  2210 124   - /usr/bin/alsa_in -j cloop -dcloop -q 1

    84  FF  2175 124   - /usr/bin/qjackctl

     1  FF    12  41   - [rcuc/1]

     1  FF     9  41   - [rcub/0]

     1  FF     7  41   - [rcuc/0]
```

----------

## PaulBredbury

You're missing the point. Perhaps this is clearer command:

```
$ ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "irq/" | sort -r | head -n 10

     -  TS  1973  34   0 grep --color=auto irq/

    90  FF    67 130   - [irq/8-rtc0]

    74  FF  1676 114   - [irq/49-nvidia]

    72  FF   270 112   - [irq/46-snd_hda_]

    70  FF    59 110   - [irq/19-uhci_hcd]

    60  FF    64 100   - [irq/1-i8042]

    60  FF    63 100   - [irq/12-i8042]

    52  FF   633  92   - [irq/47-eth0]

    50  FF    61  90   - [irq/18-uhci_hcd]

    50  FF    60  90   - [irq/16-uhci_hcd]
```

Those are IRQ handlers, e.g. for video and sound cards, able to have their relative priority changed.

I just rebooted to check (in kernel 3.4.17), and I get the same as you, without the needed threadirqs.

----------

## aCOSwt

 *PaulBredbury wrote:*   

> You're missing the point.

 

 :Embarassed:   I have been missing slightly more than just the point.

It appears I have been unknowingly running with unthreaded handlers...   :Confused: 

 *PaulBredbury wrote:*   

> I just rebooted to check (in kernel 3.4.17), and I get the same as you, without the needed threadirqs.

 

I just rebooted to check (in kernel 3.5.7), and I get the same as you, with the needed threadirqs...   :Wink: 

I stand corrected. Thank you PaulBredbury for this.

----------

## audiodef

 *aCOSwt wrote:*   

> 
> 
> Then I suggest 3.4.9 or 3.5.7 +bfsonly
> 
> 

 

Doesn't the OP state that for lowest possible latency, one should use -bfsonly?

----------

## aCOSwt

Well, you had said it was for your laptop so I imagined a more general-purpose use.

To be honest, (when not swapping), the main difference bfsonly vs full ck-patchset is coming from a very simple patch setting the default dirty ratios (these ratios fix some trade-off between throughput and latency)

The higher the dirty ratios, the more applications writing to disk will be privileged and, at least, (because you get a comfortable amount of ram used for buffering) eat all the cpu, which will keep the rest of the applications waiting.

With lower ratios, these applications writing to disk will be slowed down.

So this patch is an intentional attempt to limit the throughput, something desirable in a DAW but not necessarily on a general purpose laptop.

----------

## audiodef

I have both a desktop DAW and a laptop I use for audio when I need portability, so I'll go with -bfsonly. Thanks for 'splaining.   :Smile: 

----------

## audiodef

I compiled ck-sources and booted up, but...!

My laptop needs broadcom-sta, which needs to be compiled against the current kernel. I did so, and that wasn't a problem, but when the module actually loaded, it crashed the kernel. 

This is a problem not specific to ck-sources. It happens to other kernels and so far the only solution I know is to use a lower kernel version... unless you have any ideas for the latest ck-sources and broadcom-sta...?

----------

## aCOSwt

 *audiodef wrote:*   

> My laptop needs broadcom-sta, which needs to be compiled against the current kernel. I did so, and that wasn't a problem, but when the module actually loaded, it crashed the kernel. 
> 
> This is a problem not specific to ck-sources. It happens to other kernels and so far the only solution I know is to use a lower kernel version... unless you have any ideas for the latest ck-sources and broadcom-sta...?

 

Are you speaking of the troubles met with BCM4313 and the broadcom-sta driver ?

If this is the case then did you test keenblade's solution ? (opensource brcmsmac driver + net-wireless/brcm-firmware)

----------

## Ant P.

I think I might try this out, since zen-sources seems to be on life support.

----------

## audiodef

OK, I've tried ck-sources twice on the same desktop machine now. The first time was on an install that had been around for a while. Then for a combination of reasons I decided to backup and do a fresh install of everything. 

So now I have a fresh install, and ck-sources freezes at boot with some message about CPU1 and broadcast mode. 

What happened?   :Shocked: 

----------

## aCOSwt

 *audiodef wrote:*   

> ck-sources freezes at boot with some message about CPU1 and broadcast mode.

 

Hrmmm... could you be a little more precise ?

Which version ? which use flags ? which boot parameters ? How many cores do you get ?

Some message about CPU1 and broadcast mode... do you mean this message : 

```
Switch to broadcast mode on CPU1
```

 ?

Is the freeze definitive or does your system wake-up after a while (3-5 minutes) ?

BTW : I had forgot to mention one big advantage of the ck-sources over other *-sources is that ck-sources are a Gentoo supported kernel !

Which, amongst other things means that... posting bugs on gentoo-bugzilla is welcomed.   :Cool: 

----------

## audiodef

 *aCOSwt wrote:*   

>  *audiodef wrote:*   ck-sources freezes at boot with some message about CPU1 and broadcast mode. 
> 
> Hrmmm... could you be a little more precise ?
> 
> Which version ? 
> ...

 

3.6.2

 *aCOSwt wrote:*   

> 
> 
> which use flags ? 
> 
> 

 

None enabled. 

 *aCOSwt wrote:*   

> 
> 
> which boot parameters ? 
> 
> 

 

Straight up kernel /boot/kern.ck root=/dev/sdc3

 *aCOSwt wrote:*   

> 
> 
> How many cores do you get ?
> 
> 

 

6

 *aCOSwt wrote:*   

> 
> 
> Some message about CPU1 and broadcast mode... do you mean this message : 
> 
> ```
> ...

 

That's the one!

 *aCOSwt wrote:*   

> 
> 
> Is the freeze definitive or does your system wake-up after a while (3-5 minutes) ?
> 
> 

 

I didn't wait that long, but definitely nothing was happening after a couple of minutes. I'll let you know what happens when I get a chance to boot into ck-sources and let it sit there for 10 minutes. 

 *aCOSwt wrote:*   

>  *audiodef wrote:*   ck-sources freezes at boot with some message about CPU1 and broadcast mode. 
> 
> Hrmmm... could you be a little more precise ?
> 
> Which version ? 
> ...

 

3.6.2

 *aCOSwt wrote:*   

> 
> 
> which use flags ? 
> 
> 

 

None enabled. 

 *aCOSwt wrote:*   

> 
> 
> which boot parameters ? 
> 
> 

 

Straight up kernel /boot/kern.ck root=/dev/sdc3

 *aCOSwt wrote:*   

> 
> 
> How many cores do you get ?
> 
> 

 

6

 *aCOSwt wrote:*   

> 
> 
> Some message about CPU1 and broadcast mode... do you mean this message : 
> 
> ```
> ...

 

That's the one!

 *aCOSwt wrote:*   

> 
> 
> Is the freeze definitive or does your system wake-up after a while (3-5 minutes) ?
> 
> 

 

I didn't wait that long, but definitely nothing was happening after a couple of minutes. I'll let you know what happens when I get a chance to boot into ck-sources and let it sit there for 10 minutes. 

 *aCOSwt wrote:*   

> 
> 
> BTW : I had forgot to mention one big advantage of the ck-sources over other *-sources is that ck-sources are a Gentoo supported kernel !
> 
> Which, amongst other things means that... posting bugs on gentoo-bugzilla is welcomed.  

 

Nice!   :Smile: 

----------

## audiodef

Well, I rebooted and left it alone. Came back well after 10 minutes had passed and it was still hung on "Switch to broadcast mode on CPU1".

----------

## aCOSwt

Well, please pastebin your .config and try 3.4.9 or 3.5.7

----------

## audiodef

Here's the pastebin: http://pastebin.com/QdJwqCR3

Will try an older version and let you know what happens.

----------

## aCOSwt

Right ! While I cannot tell for sure that these are responsible for the trouble you are experiencing, there are a couple of settings I strongly disagree with (For the sake of coherency with ck-patches) and others that I would suggest to be set differently :

---------------------------------------------

1/  *Quote:*   

> CONFIG_PREEMPT_NONE=y
> 
> # CONFIG_PREEMPT is not set

 

That is almost certainly *not* what you want.

Location:

-> Processor type and features

-> Preemption Model

You definitely want to select the Preemptible Kernel (Low Latency Desktop) option.

2/  *Quote:*   

> # CONFIG_HOTPLUG_CPU is not set

 

With your hexacore, that is almost certainly *not* what you want.

Location:

-> Processor type and features

You definitely want to select the Support for hot-pluggable CPUs option.

3/  *Quote:*   

> CONFIG_IOSCHED_NOOP=y
> 
> # CONFIG_IOSCHED_DEADLINE is not set
> 
> CONFIG_IOSCHED_CFQ=y
> ...

 

With the ck patches, best performances are with the noop io scheduler. Some like the deadline but definitely not the cfq which only adds a non negligible overhead. 

Location:

-> Enable the block layer

-> IO Schedulers

This being said, I would vote for n°2 as the most probable culprit.

----------

## audiodef

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.

----------

## audiodef

Hey, what about timer frequency? I notice the options go up to 10k.

(I can't believe I overlooked the preemption model. I should know better!)

----------

## aCOSwt

 *audiodef wrote:*   

> Hey, what about timer frequency? I notice the options go up to 10k.

 

Yes! ck-sources offer you the possibility to run over 1000 hz

Keep it quitely at 1000 unless you want to save power, in which case, drop down to 300.

Note the comments made about these extra options :

- "1500 Hz is an insane value"...

- "5000 Hz is an obscene value"...

And of course : "Being over 1000, driver breakage is likely."

----------

## aCOSwt

 *audiodef wrote:*   

> 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.

----------

## audiodef

Yeah, the acronym KVM gets confused a lot... sorry.

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

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. 

3.6.2 is a no-go. I can't compile nvidia-drivers against it and thus, no xorg. 3.5.7-r1 is working, though, and JACK starts up right quick now that I have the correct preemption model set.

----------

## PaulBredbury

 *audiodef wrote:*   

> wondering why there are faster speeds here.

 

```
grep -A2 10000 /usr/src/linux/kernel/Kconfig.hz
```

 *Quote:*   

> 10000 Hz is an obscene value to use to run broken software that is Hz limited.

 

I've never heard of any examples of such broken software.

----------

## audiodef

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

----------

## aCOSwt

 *audiodef wrote:*   

> 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.   :Twisted Evil:  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.

----------

## ulenrich

Yes, but 

 *Quote:*   

>  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 ...

----------

## audiodef

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. 

Do you have any idea why ck-sources takes so long to handle keyboard-video-mouse switching?

----------

## aCOSwt

 *audiodef wrote:*   

> Do you have any idea why ck-sources takes so long to handle keyboard-video-mouse switching?

 

 :Confused:   What do you mean ? any figures ? any step to reproduce ? Which apps running ?

----------

## audiodef

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).

----------

## aCOSwt

 *audiodef wrote:*   

> 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).

 

 :Evil or Very Mad:  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 :

```

input              Logitech HID compliant keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/input/input3

hid-generic 0003   46D:C30E.0002: input: USB HID v1.10 Keyboard [Logitech HID compliant keyboard] on usb-0000:00:1d.2-2/input0

input              Logitech HID compliant keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/input/input4

hid-generic 0003   46D:C30E.0003: input: USB HID v1.10 Device [Logitech HID compliant keyboard] on usb-0000:00:1d.2-2/input1
```

On a side note, the .config you posted earlier says : CONFIG_USB_SUSPEND=y

Do you actually need that ?

----------

## audiodef

 *aCOSwt wrote:*   

> 
> 
> 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?

I will dig up my logs in a bit and post them...

----------

## aCOSwt

Following Bug 443566 and thanks Markos Chandras, 3.4.18 is out as latest release of the long term stable branch.

----------

## audiodef

Hm, I better keep ck-sources on stable. I didn't know 3.4 was stable, been using 3.5 - maybe there's stuff in there that hasn't been worked out that's been causing my hardware input device switcher to get delayed.

----------

## aCOSwt

Following Bug 447008 - and thanks to Markos Chandras, 3.4.23 is out as latest release of the long term stable branch.

----------

## audiodef

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...

----------

## aCOSwt

 *audiodef wrote:*   

> 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 ?

----------

## aCOSwt

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.

----------

## aCOSwt

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.

----------

## aCOSwt

Following BUG 459926 and thanks to Markos Chandras, the ck-sources tree has been updated in order to fix the out-of-bounds access to sock_diag_handlers security issue as reported in BUG 459124

3.7 users should upgrade to 3.7.10, 

3.6 users should upgrade to 3.6.11-r1,

3.4 users should upgrade to 3.4.34

The security fix has been backported to 3.5.7-r2 as well for the convenience of 3.5 users who cannot upgrade to 3.6

----------

## ulenrich

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

http://ck-hack.blogspot.de/2013/03/bfs-0428-for-linux-38x.html

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:

```
CONFIG_RCU_BOOST=y

CONFIG_RCU_BOOST_PRIO=88

# CONFIG_NO_HZ is not set

CONFIG_HZ_300=y

CONFIG_HZ=300
```

----------

## aCOSwt

 *ulenrich wrote:*   

> @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.

----------

## thunderrd

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   :Smile: 

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.]

So I will be going directly from 3.6.11 to 3.8.x

Regards,

tr

----------

## aCOSwt

 *thunderrd wrote:*   

> I think your plan is good, test it for a week or so more, then release a 3.8* to everyone

 

Hey... we do not get the benefice of stable keywords so... new users will automatically install the last version... hence... I must take greater care.

 *thunderrd wrote:*   

> TBH, I skipped over the 3.7.x versions on my boxen... [I would think that many others did, as well.]

 

 :Smile:   TBH... I would have skipped the 3.7 branch completely and actually waited for 3.7.9 before bumping... with a severe ewarn...

 *thunderrd wrote:*   

> waiting for the next major update. ...So I will be going directly from 3.6.11 to 3.8.x

 

Then... you... might well wait for, at least, the 3.10 branch !   :Shocked: 

Look... the CONFIG_PREEMPT_RT guys do not look that much interested in 3.7 / 3.8 as well and what I read from Greg-KH does not let me understand that he finds the 3.7 / 3.8 and 3.9 motivating enough for basing a long term support on them...   :Wink: 

----------

## xming

I have had that accounting bug for a long time, it's still present in with 3.8.2 + bfs428

```

13935 root       7   0 19416 1388 1012 R 9999  0.0  5124095h top                                                             

```

but otherwise it's running great.

----------

## thunderrd

 *aCOSwt wrote:*   

> 
> 
> Then... you... might well wait for, at least, the 3.10 branch !   

 

Don't want to do that.  Remember, 3.6.11 is still on bfs-.426

That's why I think that a 3.8x + bfs-428 is important, as the next step.  

http://ck.kolivas.org/patches/3.0/3.8/3.8-ck1/patches/

http://ck.kolivas.org/patches/bfs/3.0/3.8/

I'm running 3.8/427 for testing, will patch to 428 soonish, but would like to see 3.8/428 in portage.  Then it isn't a problem to wait for the next major revision, as long as the 428 is in there.

----------

## aCOSwt

 *xming wrote:*   

> I have had that accounting bug for a long time, it's still present in with 3.8.2 + bfs428
> 
> ```
> 
> 13935 root       7   0 19416 1388 1012 R 9999  0.0  5124095h top                                                             
> ...

 

This is certainly not the bug that ck corrected with bfs427.

I am not able to reproduce this on my ck-sources-3.6.11-r1 / ck-sources-3.4.34

But It seems from ck-hacking that Alfred Chen is experiencing it too.

----------

## aCOSwt

@ ulenrich

Just curious about your tests with RCU you posted in some other page of ck's hacking blog.

The one with :

<< CONFIG_RCU_FANOUT=32

CONFIG_RCU_FANOUT_LEAF=4 >>

What value did you assign to CONFIG_NR_CPUS ? and how many cores your machine gets at boot time ?

@ xming

Could you please post the values of RCU related CONFIG* as well as CONFIG_NR_CPUS and how many cores your machine gets at boot time ?

----------

## ulenrich

@aCOSwt, first of all I appreciate you closely watching. I am a little frustrated about BFS in this moment: I get these timeaccounting overflows again also - but less often than with linux-3.7

 *aCOSwt wrote:*   

> Just curious about your tests with RCU you posted in some other page of ck's hacking blog.
> 
> The one with :
> 
> << CONFIG_RCU_FANOUT=32
> ...

 This was just cluelessness of me. Experiencing RCU settings having an influence how often BFS time accounting fails I just experimented. I have  

CONFIG_NR_CPUS=4

also my system has only two cpus: 

```
processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 23

model name      : Intel(R) Core(TM)2 Duo CPU     P8700  @ 2.53GHz

stepping        : 10

microcode       : 0xa0b

...

processor       : 1

...

```

But, if I set up RCU_BOOST priority I have less of these overflows.

If you diff 3.7-sched-bfs-427.patch 3.8-sched-bfs-428.patch

You will see most of Cons work was about time accounting though ...

 :Sad: 

----------

## xming

 *aCOSwt wrote:*   

> 
> 
> @ xming
> 
> Could you please post the values of RCU related CONFIG* as well as CONFIG_NR_CPUS and how many cores your machine gets at boot time ?

 

```

# egrep "RCU|CPUS" .config

# RCU Subsystem

CONFIG_TREE_PREEMPT_RCU=y

CONFIG_PREEMPT_RCU=y

# CONFIG_RCU_USER_QS is not set

CONFIG_RCU_FANOUT=64

CONFIG_RCU_FANOUT_LEAF=16

# CONFIG_RCU_FANOUT_EXACT is not set

# CONFIG_RCU_FAST_NO_HZ is not set

# CONFIG_TREE_RCU_TRACE is not set

CONFIG_RCU_BOOST=y

CONFIG_RCU_BOOST_PRIO=14

CONFIG_RCU_BOOST_DELAY=440

# CONFIG_RCU_NOCB_CPU is not set

CONFIG_NR_CPUS=2

CONFIG_SPLIT_PTLOCK_CPUS=4

# CONFIG_SPARSE_RCU_POINTER is not set

CONFIG_RCU_CPU_STALL_TIMEOUT=60

CONFIG_RCU_CPU_STALL_VERBOSE=y

```

----------

## ulenrich

I also recompiled using:

```
# RCU Subsystem

CONFIG_TREE_PREEMPT_RCU=y

CONFIG_PREEMPT_RCU=y

# CONFIG_RCU_USER_QS is not set

CONFIG_RCU_FANOUT=32

CONFIG_RCU_FANOUT_LEAF=2

# CONFIG_RCU_FANOUT_EXACT is not set

# CONFIG_TREE_RCU_TRACE is not set

CONFIG_RCU_BOOST=y

CONFIG_RCU_BOOST_PRIO=97

CONFIG_RCU_BOOST_DELAY=720

# CONFIG_RCU_NOCB_CPU is not set

CONFIG_CPUSETS=y

CONFIG_PROC_PID_CPUSET=y

CONFIG_NR_CPUS=2

CONFIG_SPLIT_PTLOCK_CPUS=4

# CONFIG_PROVE_RCU_DELAY is not set

# CONFIG_SPARSE_RCU_POINTER is not set

CONFIG_RCU_CPU_STALL_TIMEOUT=32

CONFIG_RCU_CPU_STALL_VERBOSE=y

CONFIG_RCU_CPU_STALL_INFO=y

# CONFIG_RCU_TRACE is not set

```

To flaten the RCU tree a bit might be no obsticle, because I use systemd without consolekit and much less processes !?

----------

## aCOSwt

 *ulenrich wrote:*   

> To flaten the RCU tree a bit might be no obsticle

 

Do you mean you expect to flatten the RCU tree by lowering CONFIG_RCU_FANOUT_LEAF from 4 to 2 ?

With a greater number of CPUs (>64 in this particular case), things would just go the other way round.

With CONFIG_NR_CPUS=2 and CONFIG_RCU_FANOUT=32, it just cannot be more flat than it is already.

as CONFIG_NR_CPUS < CONFIG_RCU_FANOUT * CONFIG_RCU_FANOUT_LEAF, you get a single level tree.

On my core II duo, I set CONFIG_NR_CPUS=2 / CONFIG_RCU_FANOUT=2 / CONFIG_RCU_FANOUT_LEAF=2 and my tree is not more flat than yours...

@ ulenrich & xming : Do you sometimes experience negative idle times ?

----------

## ulenrich

I just used the above configured Bfs Linux-3.8.2 kernel and had the same time accounting bugs. But later on.

[edit] Idle times keep positive numbers - mostly over 90 percantage of "top". 

Or what number do you refer to?

----------

## aCOSwt

 *ulenrich wrote:*   

> Idle times keep positive numbers - mostly over 90 percantage of "top". 
> 
> Or what number do you refer to?

 

I was referring to /proc/stat, fourth column of the cpu rows.

I think that xming's problem and yours are not related.

This because I think xming is running tickless while you are not and because the figures he announces are just absurd.

I xming's trouble is the one I suspect, then it should also display negative idle times.

EDIT : @ulenrich : of course, you boot your -ck with threadirqs in the boot command line ! (Full credits to PaulBredburry   :Wink:  )

----------

## ulenrich

Is this the same as threadirqs?

```
CONFIG_IRQ_FORCED_THREADING=y
```

I ever had this set.

 *Quote:*   

> because the figures he announces are just absurd

 

My figures look exactly the same.

A phenomenon to mentions: These "million" time numbers appear when heavy compiling. The first are

ar

lines of the assembler. But when happened afterwards also other programs have it. It looks that bad for me personal that I misstrust my system then and start a non BFS kernel ...

----------

## aCOSwt

 *ulenrich wrote:*   

> Is this the same as threadirqs?
> 
> ```
> CONFIG_IRQ_FORCED_THREADING=y
> ```
> ...

 

It is related.

But, in order for this config setting to be effective at runtime, you must especially activate it at boot time, appending threadirqs to your boot command line.

Then, you will notice that all irqs default to an RT priority of 50.

Regarding this problem of time accounting, you should make sure that no task (including rcu) gets a higher priority than the rtc0 interrupt.

=> either increase the rtc0 interrupt priority or decrease the priority of others.

----------

## ulenrich

@aCOSwt, Uuups. I misunderstood as if "IRQ_FORCE_" 

.. bloody little naming differences. 

And also yes IRQ priority > RCU priority sounds logical ...

[to be edited with results] ...

----------

## aCOSwt

 *ulenrich wrote:*   

> @aCOSwt, Uuups. I misunderstood as if "IRQ_FORCE_"

 

 :Embarassed:   I have had as well !   :Very Happy: 

 *ulenrich wrote:*   

> [to be edited with results] ...

 

With the results, watch also in /proc/pid/status, the number of non voluntary context switches (last line of the file) for each pid matching the process id of the irqs that matter.

----------

## ulenrich

Yeah, this top looks different! As you see I changed RCU_BOOST_PRIORITY to 38 which results "-39" in the output: 

```
top -b -n 1 -u root -o -PR |grep -e migration -e irq -e rcu -e kthread -e ksoft | cat

    8 root      rt   0       0      0      0 S 0.000 0.000   0:00.00 migration/0

   16 root      rt   0       0      0      0 S 0.000 0.000   0:00.00 migration/1

   25 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/9-acpi

   47 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/40-PCIe PME

   48 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/41-PCIe PME

   49 root     -51   0       0      0      0 S 0.000 0.000   0:00.44 irq/42-ahci

   62 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/8-rtc0

  199 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/20-ehci_hcd

  200 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/18-ehci_hcd

  202 root     -51   0       0      0      0 S 0.000 0.000   0:00.08 irq/21-ohci_hcd

  203 root     -51   0       0      0      0 S 0.000 0.000   0:00.03 irq/19-ohci_hcd

  219 root     -51   0       0      0      0 S 0.000 0.000   0:00.05 irq/23-snd_hda_

  423 root     -51   0       0      0      0 S 0.000 0.000   0:00.00 irq/43-eth0

  428 root     -51   0       0      0      0 S 0.000 0.000   0:00.15 irq/23-b43

  792 root     -51   0       0      0      0 S 0.000 0.000   0:00.19 irq/21-nvidia

   10 root     -39   0       0      0      0 S 0.000 0.000   0:00.00 rcub/0

    9 root      -2   0       0      0      0 S 0.000 0.000   0:00.12 rcuc/0

   14 root      -2   0       0      0      0 S 0.000 0.000   0:00.13 rcuc/1

    2 root       1   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd

    3 root       1   0       0      0      0 S 0.000 0.000   0:00.94 ksoftirqd/0

   11 root       1   0       0      0      0 S 0.000 0.000   0:00.07 rcu_preempt

   12 root       1   0       0      0      0 S 0.000 0.000   0:00.00 rcu_bh

   13 root       1   0       0      0      0 S 0.000 0.000   0:00.00 rcu_sched

   15 root       1   0       0      0      0 S 0.000 0.000   0:01.32 ksoftirqd/1

```

Did the default handling of CONFIG_IRQ_FORCED_THREADING change between the last kernel major releases (I mean you hadn't to specify the boot parameter?) ? I ask because I once hadn't had this time accounting overflow using BFS ...

With the "voluntary" watching you mean the pids of which have time accounting overflows? 

(Which I don't have yet - might come along after some hours ...)

----------

## aCOSwt

 *ulenrich wrote:*   

> Did the default handling of CONFIG_IRQ_FORCED_THREADING change between the last kernel major releases

 

No.

 *ulenrich wrote:*   

> I ask because I once hadn't had this time accounting overflow using BFS

 

If the changes you are doing have any impact on what you report about time accounting problems then these time accounting problems are more system's load dependent than kernel version dependent.

 *ulenrich wrote:*   

> With the "voluntary" watching you mean the pids of which have time accounting overflows?

 

No, I meant particularly the pid of rtc0.

BTW, of course with two cores, you do not "play" with CONFIG_CGROUPS and cpu affinity, do you ?

----------

## ulenrich

I am unsure what cgroups would I need using "Systemd", is it different to the namespaces needed by Systemd?

```
CONFIG_CGROUPS=y

# CONFIG_CGROUP_DEBUG is not set

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

# CONFIG_CGROUP_HUGETLB is not set

# CONFIG_CGROUP_PERF is not set

CONFIG_BLK_CGROUP=y

# CONFIG_DEBUG_BLK_CGROUP is not set

# CONFIG_NETPRIO_CGROUP is not set
```

And here my irq8/-rtc0  status:

voluntary_ctxt_switches:        3

nonvoluntary_ctxt_switches:     0

----------

## ulenrich

I have just seen it again

inducing heavy duty into my system (compile kernel + kdelib)

as ever the assembler - see the second "===" line:

= == ==   5.1   0:07 RN+  emerge   @ 1465s

                 4.7   0:00 RN+  cc1

                 4.5   0:00 RN+  cc1

                 3.4   7:56 Ss+  X

                 1.9   4:31 Sl   kwin

                 1.0   0:32 Sl   firefox

                 0.6   1:25 Rl   yakuake

                 0.5   0:09 SN+  emerge

= == ==  207725234 21114581:29 SN+ as   @ 1470s

                 5.0   0:07 RN+  emerge

                 4.5   0:00 RN+  cc1

                 3.5   0:00 RN+  cc1

                 3.4   7:57 Ss+  X

                 1.9   4:31 Sl   kwin

                 1.0   0:32 Sl   firefox

the status of irq/8-rtc didn't change (see above)!

----------

## aCOSwt

please post the output of 

```
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
```

----------

## ulenrich

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

hpet

These above time accounting overflows where then a a thread ksoftirq

I compiled a new BFS kernel having RCU default boost proiority, which I run now.

----------

## aCOSwt

 *ulenrich wrote:*   

> These above time accounting overflows where then a a thread ksoftirq

 

With 2 cores, you should always get 2 ksoftirq daemons.

They are more or less consuming cpu depending on the load of the system because the more load => the more softirqs serviced < softirqs triggered.

Well this is simply confirming your system is under heavy load.

----------

## ulenrich

There are two ksoftirqd/0 or 1

I saw the time overflow again at the "as" assembler compile 

After compiling - without heavy load - the time accounting overflow switched to one ksoftirqd/n .

I can say it, because I sorted top output by TIME+ sum. The other ksoftirqd entry therefore I didn't see.

I now try without any special RCU boost priority. 

But with BFS and boot parameter threadirqs - I will see what happens ...

[edit] Result: without RCU boost priority set high the overflow appears early without any heavy duty jobs ...

----------

## aCOSwt

 *ulenrich wrote:*   

> without RCU boost priority set high the overflow appears early without any heavy duty jobs ...

 

OK, I just cannot manage to reproduce on a 2 cores. (3.4.34 / 3.6.11-r1) kwin + make -j2 + 4 SCHED_FIFO threads at a higher priority than the one given to the rcu priority boosting.

But I do not use top.

Considering your remark about the ksoftirq daemons, CONFIG_IRQ_TIME_ACCOUNTING is set with the BFS but is not a default setting under a stock Linux kernel.

When you make your non-BFS kernel. Do you specifically set it ? If not then please test under a non-BFS kernel + CONFIG_IRQ_TIME_ACCOUNTING.

( General setup -> CPU/Task time and stats accounting  -> Cputime accounting )

----------

## ulenrich

 *aCOSwt wrote:*   

> Considering your remark about the ksoftirq daemons, CONFIG_IRQ_TIME_ACCOUNTING is set with the BFS but is not a default setting under a stock Linux kernel.
> 
> ... please test under a non-BFS kernel + CONFIG_IRQ_TIME_ACCOUNTING

 What bugs me here: 

normally you choose, but the BFS config patch does select both!

```
grep ACCOUNTING config-3.8.2-1087.cfs config-3.8.2-1091.bfs 

config-3.8.2-1087.cfs:# CONFIG_TICK_CPU_ACCOUNTING is not set

config-3.8.2-1087.cfs:CONFIG_IRQ_TIME_ACCOUNTING=y

config-3.8.2-1087.cfs:CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y

config-3.8.2-1091.bfs:CONFIG_TICK_CPU_ACCOUNTING=y

config-3.8.2-1091.bfs:CONFIG_IRQ_TIME_ACCOUNTING=y

config-3.8.2-1091.bfs:CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
```

Today I tried for hours to provoke the time accounting overflow using an CFS kernel with CONFIG_IRQ_TIME_ACCOUNTING=y.

Not possible to provoke the overflow without BFS!

Also I had the idea to try the BFS kernel with CONFIG_NO_HZ 

as most users do. But no luck, no difference.

@all, who can reproduce these time accounting overflows?

You can use this script "mytop" 

```
#!/bin/bash

sleepy=3

[ -n "$1" ] && [ "${1%%[1-9]*}" == "" ] && sleepy=$1

export p=1

[ -n "$2" ] && [ "${2%%[0-9]*}" == "" ] && p=$2

echo "linux-$(uname -r -m -p)"

echo "Run  Sleep  Duninterruptible  Tstoped  Xdead  Zombie"

echo "<notNice  Nlow  LioWait  sLead  +foreground  lmultiThr"

echo -e "%CPU   TIME STAT COMMAND"

     ps -e -o pcpu,bsdtime,stat,comm --no-heading --sort -pcpu \

      |head -n $p

while sleep $sleepy ; do

     ps -e -o pcpu,bsdtime,stat,comm --no-heading --sort -pcpu \

      |head -n $p

done
```

----------

## aCOSwt

@ulenrich : Could you please try an urw-locks patched ck.

Either you patch yourself or simpler : emerge ck-sources (3.4.34 or 3.6.11-r1) with both experimental and urwlocks use flags set.

----------

## ulenrich

No, I don't go back, because I already have

linux-headers-3.8

glibc-2.17

This urwlocks patch is also placed in the BFS ck1 for linux-3.8. But I think it has no meaning. grep urwlocks.h doesnt show any inclusion into the bfs patch?

As of now for me the unpatches linux-3.8 sources suites well: After getting rid of some of the cgroups it appears to have even better interactivity performance!

----------

## aCOSwt

 *ulenrich wrote:*   

> This urwlocks patch is also placed in the BFS ck1 for linux-3.8. But I think it has no meaning. grep urwlocks.h doesnt show any inclusion into the bfs patch?

 

Of course, it gets no meaning at all... alone !

As up to 3.7, it makes a little more sense when considered together with the bfs426-grq_urwlocks.patch...

----------

## Ant P.

Okay, I finally switched all my systems to this.

zen-sources @ v3.8 had some huge radeon performance improvements, but it was also a million times less stable than the 3.7 series. I can live without coloured dmesg lines...

----------

## aCOSwt

You are welcome Ant P.

----------

## aCOSwt

Following BUG 462190 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :

- Push the 3.8.3 early release,

- Fix the deadlock regression in ZFS impacting on >= 3.6 kernels.

3.7 users can upgrade to 3.7.10-r1, 

3.6 users can upgrade to 3.6.11-r2,

If they are using ZFS together with the Memory Resource Controller for Control Groups (CONFIG_MEMCG=y)

About the 3.8.3 early release, please note that :

- The upgradeable read/write locks optional patch has not been made available with this release.

- The full patchset no longer alters stock-Linux default settings of the dirty ratios. If you need advices on how to reset these as they used to be with < 3.8, just ask here.

Please also note that an always increasing number of security issues is being reported against 3.5.7 (See http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6536 up to 2012-6549

We have no intention to provide security fixes for this branch => All 3.5 users should definitely upgrade to 3.4.34 / 3.6.11-r2 or 3.7.10-r1

----------

## jasn

 *aCOSwt wrote:*   

> The full patchset no longer alters stock-Linux default settings of the dirty ratios. If you need advices on how to reset these as they used to be with < 3.8, just ask here.

 

I'd just ask a more generalized question regarding switching my general purpose laptop from gentoo-sources to ck-sources. Other than switching the scheduler to Noop, are there any other suggestions for kernel settings using ck-sources-3.8.3, (emerged without any USE flags enabled)? Should the dirty rations be set to anythig specific, etc.?

Thanks..

----------

## Ant P.

Just wanted to mention, 3.8.3-ck has been rock stable for me. I'm at a loss why 3.8-zen was such a trainwreck in comparison. Probably my own fault.  :Laughing: 

----------

## ulenrich

 *jasn wrote:*   

>  *aCOSwt wrote:*   The full patchset no longer alters stock-Linux default settings of the dirty ratios. If you need advices on how to reset these as they used to be with < 3.8, just ask here. 
> 
> ... 
> 
> Should the dirty rations be set to anythig specific, etc.?

 

I think these prefered ratios of Con Kolivas where a matter of taste from the beginning: less disk writes 

a) better performane - contra - low performance when low in ram

b) longer power on battery with laptops.

In times when ram was about 1GiB it was a fine taste, but nowadays you just can ignore the ratios:

1. more and more ram that even a larger ratio will not show much swap activity.

2. You have more and more ssd disks, which are essentially the same as electronical ram and same as fast.

And on the other hand for a power workstation there is a use case of higher ratios:

3. using many virtual systems in paralle could easily eat up a lot of ram. In addition if you then use the very modern technique of recent kernels to "defrag" your ram and use it efficiently thereby you will get hit having too low ratios: When havily using transparent hugepages, there is a background defragmenter at work to deliver these. And this needs a little free working place ... (But I am not sure if I have understood all of it correctly)

----------

## aCOSwt

 *jasn wrote:*   

> switching my general purpose laptop.

 

There are actually not many significant differences at kernel config time.

- Features of the stock linux that BFS superbly ignores or dislikes are disabled,

Group scheduling, RCU torture facilities... features nobody would want anyway...

- Important features that BFS relies on are forced "y" (Fine granularity task level IRQ time accounting)

So you could almost copy/paste your stock-linux .config file and make oldconfig, if you are happy with your CFSed-Linux settings.

BTW : My opinion is that you are correct when preferring the No-Op IO scheduler with BFS.

You'll experience and tweak the impact of BFS from userspace.

A/ MAKEOPTS="-jN" with N exactly equal to the number of active cores.

It is common sense that whatever system will be more efficient running a cpu-bound process split into exactly N tasks than running the same process split into N+1 tasks.

The CFS does not share this evidence.

If your CFSed system has to deal with exactly N cpu-bound tasks, you'll observe some iddle time anyway   :Shocked: 

And with CFS, the more tasks you get, the less iddle time you'll observe.

CFS is not more efficient with N+1 tasks to run, it is just less-(less-efficient) than with only N.

Because the BFS makes a more efficient use of the cpus, (the iddle time is close to null when running exactly N cpu-bound tasks) the logic is safe !   :Cool: 

B/ /proc/sys/kernel/rr_interval

This is where you can read/write the only BFS tuneable.

That is the round robbin interval in ms.

In short : the longest duration two tasks of the same nice level will be delayed for.

It defaults to 6 and can be adjusted from 1 to 1000.

- Practically speaking : Decrease it down to 3 if latency is everything for you at the entire expense of the throughput, Increase it up to 300 if throughput is everything for you at the full expense of latency.

- Even more practically speaking with a general-purpose laptop... keep the default value ! (That's why defaults are defaults aren't they ?)   :Twisted Evil: 

- I personally set it to 3 on my DAW and keep default on my general-purpose desktop.

- PaulBredburry who has accumulated a lot of experiments and experience, used to recommend 7 for gamers.

C/ Dirty-Ratios

BTW, This is in no way BFS-specific.

These values (readable/writable) in /proc/sys/vm/dirty_ratio and /proc/sys/vm/dirty_background_ratio basically control which task will actually achieve disk-writes and when.

- dirty_ratio is the percentage of ram that can be dirty before the task actually responsible for the disk write requests starts writing to disk by itself.

- dirty_background_ratio is the maximum percentage of the ram that can be dirty before it is written to disk by a daemon.

In the 2.6.20 times, stock-linux defaulted to respectively 40 and 10 but considering the always increasing amount of ram available Linus found these values just insane and brought them down to their current value of 10 and 5 respectively.

How does this impact and why was the ck-patchset altering these values ?

You understand easily that the task actually requesting disk writes will in fact... fill the RAM until the dirty limit is reached.

That is also to say that this task will *not* block until the dirty limit is reached and will fully consume its entire time-slices.

In other words an actually IO-bound task behaves exactly as a very-very-hungry CPU-bound task until the dirty limit is reached.

This, of course will happens at the full expenses of interactivity and... on everything else than a server... you don't want this.

That is why the ck-patchset was used to lowering these values down to 1 (both)

This making so the tasks actually responsible for the disk-writes will very early write by themselves and work at the pace of the device, that is also to say... will be blocked most of the time as any good old true honest IO-bound task would be.   :Cool: 

These values (1/1 both) still make sense.

Unfortunately a bunch of userspace utilities (upower-like thingies) arbitrarily play with these values whenever you launch your DE / come-back from hibernation / switch powersources...

And when they happen to "Switch back to kernel defaults" they do not actually. They actually push hardcoded 10 and 5 !   :Rolling Eyes: 

So these utilities that you are likely to get and want with your laptop actually render the initial settings by the ck-patch vain.

But... once again... the values the ck-patchset was setting as defaults still make sense, you just need to use another much more complicated (and power manager dependent) way to set them on a permanent basis.  :Evil or Very Mad: 

OK, that's all for configuration specific.

At the end of the day, you'll realize that you do not obtain the best from BFS through configuration. You actually obtain the best form BFS by selecting appropriate scheduling models / priority levels for the processes you run.

----------

## jasn

Thanks very much for the complete description, and suggestions. I've changed my scheduler to noop, already had my /etc/genkernel.conf and /etc/portage/make.conf set to MAKEOPTS="-j8" for my core-i7 laptop, and am happy to leave /proc/sys/kernel/rr_interval at the default 6.

So the only change I now want to make is to set my /proc/sys/vm/dirty_ratio and /proc/sys/vm/dirty_background_ratio to 1. I can do it from the terminal, however when I tried to add the commands to a /etc/local.d start file for setting this upon system boot, they didn't take. When my system was up, I cat'ted both values and they were set to the system default of 10 and 5. Weird huh?.. For now I just do it from a terminal window after bootup..

Anyway big thanks again.. (and thanks for the maintaining of the ck-kernel sources too!)

Jason

----------

## aCOSwt

 *jasn wrote:*   

> So the only change I now want to make is to set my /proc/sys/vm/dirty_ratio and /proc/sys/vm/dirty_background_ratio to 1. I can do it from the terminal, however when I tried to add the commands to a /etc/local.d start file for setting this upon system boot, they didn't take. When my system was up, I cat'ted both values and they were set to the system default of 10 and 5. Weird huh?.. For now I just do it from a terminal window after bootup..

 

The best practice to automatically set these values at init time is to put this configuration as part of /etc/sysctl.d :

```
# cat /etc/sysctl.d/dirty_ratio.conf 

vm.dirty_ratio=1

vm.dirty_background_ratio=1
```

But remember as written previously... these settings will remain as long as nothing gets the questionable initiative to silently launch things such as /usr/libexec/upowerd behind your back...

(starting KDE does this)   :Evil or Very Mad: 

----------

## aCOSwt

 *ulenrich wrote:*   

> @all, who can reproduce these time accounting overflows?

 

ACK   :Exclamation:   I incidentally managed to reproduce it on a 3.7.10-r1. (bfs427)

On a couple of as displaying the same "TIME"=5124095h and associated %cpu=200 (It's a core II duo) concurrently with opera:libflashp displaying the same "TIME" but with associated %cpu=3.6 and ksoftirqd/0 displaying the same time and a %cpu=0.0

Sometime after, the interrupt handler of my SATA devices had registered into the club...

Things are going to be a lot more clear from now. Well, I mean I now know from where to start my investigations.

I just love the idea of filling the code of a scheduler with breakpoints...   :Very Happy: 

Anyway... for the time being, the value looks like a negative number, this in turn smelling some inappropriate cast somewhere, so I'll first look at the code...

EDIT : A couple of curious observations on ksoftirqd/0 :

Looking at its sole thread (/proc/pid/task/tid/stat), I can watch absolutely sensible utime and stime.

However : Looking at /proc/pid/stat things are much more curious as :

- utime = tid's utime,

however : stime is stuck to some incredible value... which as a number... has the astonishing particularity to look exactly like leftmost decimal digits of the number displayed in the field supposed to represent... the rsslim   :Exclamation:   :Shocked:   :Shocked: 

This field being in turn the decimal representation of 0xFFFFFFFFFFFFFFFF... Normal !

EDIT2 :  *Con wrote:*   

> good work, now go in and fix it

 

 :Evil or Very Mad:  ulenrich ! I... hmmm... I... hate you !   :Evil or Very Mad: 

----------

## ulenrich

@aCOSwt, 

what bugs me: From the point there was a time accounting over- or underflow, which is late and only when I compile a big ebuild (e.g. gcc-ebuild and beginning with assembler threads), then more underflows appear afterwards not related to the build.  In a manner like there is the template for new processes damaged (But not all new processess).

If some users cannot reproduce this weird behavior (like CK himself cannot),  perhaps there is an influence of the topology of the processor used: I have just one core2-duo with common cache. If there are more cpus some additional numa code takes more care of it?

----------

## aCOSwt

 *ulenrich wrote:*   

> what bugs me: From the point there was a time accounting over- or underflow

 

It is definitely not a problem of time accounting Xflow !

Therefore : Nothing bugs you !

Problem solved !

OK, there's a bug and I'll put some effort to fix it at the condition I find a way that does not force me to increase the overhead or to rethink the entire accounting stuff in bfs from scratch.

I hope I will succeed, if I don't, I will publicly tell what I think of process time accounting / userspace process time accounting utilities / those who design process time accounting code / those who use process time accounting utilities !

And will get banned !

In the mean time, if time accounting is something important for you, do it at the task level. If the accuracy of task time accounting is also questionable (while being still far better than what we obtain from CFS), task time accounting gets at least the merit of being meaningful and, as far as I can observe, not impacted by this bug.

----------

## xming

I can reproduce almost 100% when I launch 'top', as for big compile 'as' gets that a lot too.

And for me I don't think that it has to do with startup template, because I can see 'top' sometimes has normal values on the first display, but gets crazy values after refresh.

I always thought this might have to do with the clocksource, as the TSC on my PC is unstable, but TBH I have never seen crazy values with CFS.

Just my 2 cents.

----------

## PaulBredbury

 *aCOSwt wrote:*   

> recommends 7 for gamers

 

Do I?  :Laughing: 

Actually, what I find best these days is:

```
echo 4 > /proc/sys/kernel/rr_interval
```

Maybe I'm getting fussier. Not sure what's best for people in general.

Games are smoother with the boot option clocksource=jiffies, because hpet is broken and my "TSC is unstable".

Edit: I just tested dhewm3's timedemo, and an rr_interval of both 1 and 20 result in the same 46.8 fps. Tested with clocksource of jiffies, and acpi_pm. So not currently sure  :Confused: Last edited by PaulBredbury on Fri Mar 22, 2013 1:42 pm; edited 4 times in total

----------

## aCOSwt

 *xming wrote:*   

> I always thought this might have to do with the clocksource, as the TSC on my PC is unstable

 

It is not related to the clocksource. I your TSC is "not stable" (most probably because it "halts in idle") then your system won't use it.

 *xming wrote:*   

> I have never seen crazy values with CFS.

 

Values with CFS are not crazy.(*)

They are just : inaccurate!

Once again it's not formally a problem of time accounting because time accounting is correct at the task level. (The only thing the scheduler actually minds about anyway)

=> If you want to do real time-accounting, do it at the task level !

And because I might not have made things clear enough... yet   :Rolling Eyes:  :

If you are interested in meaningful and accurate and not bugged accounting values for a single-threaded process of pid=P, read them in /proc/P/task/P/stat !

top, per default, reads these values from /proc/P/stat and these are the values that are concerned by the bug we are discussing about.

But once again, even if bugfree and under whatever system, these /proc/P/stat values are : Meaningless !   :Razz: 

If you absolutely want to use top, at least use it with the -H option.

(*) Well... most of the times not crazy. Because it is possible to conceive a cpu-bound task that will "eat" 100% cpu while CFS will report... 0 ! (If it is scheduled at the "right" time)

----------

## aCOSwt

 *PaulBredbury wrote:*   

>  *aCOSwt wrote:*   recommends 7 for gamers 
> 
> Do I? 

 

OK... I changed for "used to recommend"   :Razz: 

 *PaulBredbury wrote:*   

> Actually, what I find best these days is:
> 
> ```
> echo 4 > /proc/sys/kernel/rr_interval
> ```
> ...

 

No no... you just... like to contradict me.    :Very Happy: 

I don't really mind, each time you do, I learn something !   :Twisted Evil: 

----------

## xming

 *PaulBredbury wrote:*   

> 
> 
> Games are smoother with the boot option clocksource=jiffies, because hpet is broken and my "TSC is unstable".
> 
> 

 

It used to be like that on my PC as well, when TSC is unstable (and my motherboard doesn't have hpet) kernel fails back to acpi_pm, which was very slow, playing a game which calls many gettimeofday() would result 40% in sys time. Changing the clocksource to jiffies reduced that to less than 5%.

But somewhere in the course of 3.x apci_pm got really much better, so this is my clocksource now.

----------

## PaulBredbury

 *xming wrote:*   

> apci_pm got really much better, so this is my clocksource now.

 

Yeah, I've switched back to:

```
hpet=disable clocksource=acpi_pm processor.max_cstate=1
```

Because I suspect clocksource=jiffies was making games (e.g. NFS: Most Wanted) unstable, due to not being a high-resolution timer (nor is "tsc").

And hpet=disable is needed, to really make hpet die, so dmesg shows:

```
hpet_acpi_add: no address or irqs in _CRS
```

And processor.max_cstate=1 (2 is not sufficient) improves the TSC from:

```
Marking TSC unstable due to TSC halts in idle
```

to:

```
Refined TSC clocksource calibration: 2526.999 MHz.
```

This is with kernel 3.4.37.

Hmm, now I know the trick for making the TSC stable, clocksource=tsc (rather than acpi_pm) might be best - is the fastest. Let's see if it causes any problems...

Edit: tsc is best for me - stable and smooth in games and running virtualbox. I don't even need to specify clocksource=tsc - it is chosen automatically. So my kernel commandline, in full, is now:

```
usbhid.mousepoll=2 apparmor=1 vmalloc=256M hpet=disable processor.max_cstate=1
```

Last edited by PaulBredbury on Mon Mar 25, 2013 6:10 am; edited 1 time in total

----------

## Ant P.

Okay, looks like I have a problem...

I have one UEFI box with an AMD E-350 and these in .config:

```

CONFIG_EXTRA_FIRMWARE="radeon/PALM_me.bin radeon/PALM_pfp.bin radeon/SUMO_rlc.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

CONFIG_DRM_RADEON=y

CONFIG_DRM_RADEON_KMS=y

CONFIG_FB=y

CONFIG_FB_EFI=y
```

This works fine in ck-3.7.10, but not 3.8.3. At the point where it tries to switch from efifb to radeondrmfb I get a hard crash and the screen loses signal. Nothing in syslog after it happens and I don't really know any way of getting the oops message out of there otherwise (since there's no video after it happens)...

----------

## thunderrd

I've also found something interesting regarding 3.8.3.

In 3.6.11, when running the Folding@home smp client, htop and top both report around 90-95% CPU usage, which is correct, considering there are other light processes running.

I installed the sources for 3.8.3, ran 'make oldconfig', configured the new settings, and booted into it.  Now, htop reports 102-104% CPU usage, which is impossible.  top, on the other hand, is accurately reporting the usage at 90-95% as before.  I thought that perhaps I had configured something wrong in the new kernel options, so I did it again - this time simply copying the .config from 3.6.11 into 3.8.3, and running make (not configuring the new options).

I had the same result - htop reporting over 100% CPU usage on the one process alone.

Since 3.6.11 has BFS 426, and 3.8.3 has BFS 428, I am suspecting it is something in the 428 code that causes this buggy behavior relative to htop, but I don't know what it could be.  It does not affect any functionality that I can see so far, but it would be interesting to know why it's happening.

It might be helpful to find out where top reads its CPU information from vs where htop gets it from, because that might point to something in the BFS code [if BFS is indeed where the problem lies].

TR

----------

## aCOSwt

 *Ant P. wrote:*   

> Okay, looks like I have a problem...
> 
> ...
> 
> This works fine in ck-3.7.10, but not 3.8.3. At the point where it tries to switch from efifb to radeondrmfb I get a hard crash and the screen loses signal.

 

I (un)fortunately do not get the hardware to test/reproduce this.

However, from what you write, my first suspect would be : http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=62a3dcc78d04dcd84276eaa7a40dec1066054532

This patch was backported to the 3.4 branch with 3.4.34 but neither to the 3.7 nor to the 3.6

=> If you find the summary of this patch coherent with more precise observations you might have made on your system, you can :

- Try to reproduce this bug under =ck-sources-3.4.34

And, if you manage to reproduce it and, if you absolutely want the 3.8.3... you could then retry after reverting this patch.

-----------------------

BTW as a general note TWIMC : As per The Gentoo Linux Kernel Guide, the ck-sources are listed among the rare supported kernel packages => Bug submissions are welcomed on Gentoo's bugzilla, under the Gentoo Linux product / Core system component.

Of course I do not mean that bug reports are not welcomed as part of this thread, I only mean that reporting on Bugzilla might guarantee a wider audience among devs and incidentally make the bug easier to tackle and track.

----------

## aCOSwt

 *thunderrd wrote:*   

> when running the Folding@home smp client, htop and top both report around 90-95% CPU usage...Now, htop reports 102-104% CPU usage, which is impossible.

 

Which fields of htop screen are you referring to ? Upper right load averages ? Upper left per cpu % ? %CPU column of the smp client ? / Which fields of top launched with which parameters ?

 *thunderrd wrote:*   

> simply copying the .config from 3.6.11 into 3.8.3, and running make (not configuring the new options).

 

Of course you know that, irrespective of your %CPU problem, this is wrong practice.

----------

## thunderrd

 *aCOSwt wrote:*   

> Which fields of htop screen are you referring to ? Upper right load averages ? Upper left per cpu % ? %CPU column of the smp client ? / Which fields of top launched with which parameters ?

 

The CPU% column.

 *aCOSwt wrote:*   

> Of course you know that, irrespective of your %CPU problem, this is wrong practice.

 

Err...yes.  Maybe I wasn't clear enough when I said I'd configured the new kernel already, and it exhibited the problem, so I did this simply to localize the buggy behavior.  It's what leads me to believe that the problem lies with BFS 428 and not the kernel itself; since I built 3.8.3 the second time with exactly the same options set, and its behavior is different from 3.6.11, that would appear to be the case.  Of course it was only as a test.   :Smile: 

----------

## ryao

 *aCOSwt wrote:*   

> Following BUG 462190 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :
> 
> - Push the 3.8.3 early release,
> 
> - Fix the deadlock regression in ZFS impacting on >= 3.6 kernels.
> ...

 

ZFS is affected regardless of whether CONFIG_MEMCG is in effect or not. On the other hand, the patch that caused the regression is only useful when three conditions are met:

CONFIG_MEMCG is enabled

You are using memory cgroups

You do heavy IO inside a memory cgroup that has a small memory limit.

I do not know of any deployed system that satisfies all 3 conditions.

----------

## kernelOfTruth

 *aCOSwt wrote:*   

>  *ulenrich wrote:*   This urwlocks patch is also placed in the BFS ck1 for linux-3.8. But I think it has no meaning. grep urwlocks.h doesnt show any inclusion into the bfs patch? 
> 
> Of course, it gets no meaning at all... alone !
> 
> As up to 3.7, it makes a little more sense when considered together with the bfs426-grq_urwlocks.patch...

 

here's an updated patch:

http://pastebin.com/cpqdXZye

currently re-compiling my kernel & will try it with a reboot later

any differences and/or improvements you guys noticed with urwlocks in the past ?

edit:

http://ck-hack.blogspot.co.at/2012/06/upgradeable-rwlocks-and-bfs.html?showComment=1339530561532#c3786277741482055329

edit.

----------

## aCOSwt

 *kernelOfTruth wrote:*   

> here's an updated patch: http://pastebin.com/cpqdXZye

 

Thank you but... warning !

I submitted a patch to Con a couple of weeks ago that looks like... nearly exactly the same as yours...

(We have certainly built it almost the same way)

But Con... did not commit it in his repo so... Might have not been pleased with ?

 *kernelOfTruth wrote:*   

> any differences and/or improvements you guys noticed with urwlocks in the past ?

 

Yes, the sysbench --test=threads test reports figures that are closer to CFS when BFS is usually more than 30% better in this area.   :Shocked: 

On a coreII duo, under ck-sources-3.5.7 with 64 threads, 2000 thread-yields, 16 thread-locks, sysbench reports a total time of 

- CFS : 8,8651 s

- (grq-spinlocked) BFS : 5,9689 s

- (urw-locked) BFS : 7,9726 s

BTW, this change is not really meant to stand alone. It is made available with no other goal per se than to test its robustness.

Con gets in his mind a couple of improvements to BFS that are yet only half done and that would rely on this change.

----------

## aCOSwt

 *ryao wrote:*   

> ZFS is affected regardless of whether CONFIG_MEMCG is in effect or not.

 

I stand corrected !

As you are the one who works on the problem, you should with no doubt be trusted more than what I had understood from what I had read.

----------

## aCOSwt

 *Ant P. wrote:*   

> Okay, looks like I have a problem...

 

Another possible track starts from there : https://lkml.org/lkml/2013/2/21/461

With Linus comment : "Doing things like blindly trusting the firmware data without even validating it is a really really bad idea."

If you confirm then https://lkml.org/lkml/diff/2013/3/26/661/1 is the patch for correcting the bug.

EDIT : Note that nvidia hardware should be concerned as well by this bug, https://lkml.org/lkml/diff/2013/3/26/669/1 is the patch for nouveau.

EDIT2 : The patches mentioned above are apparently not included in the upstream's 3.8.5 patch (I won't bump)

EDIT3 : And not in the upstream's 3.8.6 patch either. (I won't bump)

----------

## Ant P.

Yeah, today on a whim I went and tried the zen-sources git clone I keep around (`make nconfig` calls it 3.8.6) and still get that problem. No big deal in my case, but I bet more than one person out there's having a bad day...

I tried making radeon a module instead of built-in. It still hangs for a while but I can eventually SSH in. dmesg says this, posting here for reference:

```
[    3.022877] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

[    3.022895] IP: [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]

[    3.022961] PGD 2444e2067 PUD 2444e1067 PMD 0 

[    3.022970] Oops: 0002 [#1] SMP 

[    3.022976] Modules linked in: snd_hda_intel(+) radeon(+) snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer drm_kms_helper snd ttm soundcore

[    3.022998] CPU 0 

[    3.023004] Pid: 182, comm: modprobe Not tainted 3.8.6-zen+ #9  

[    3.023012] RIP: 0010:[<ffffffffa008617f>]  [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]

[    3.023049] RSP: 0018:ffff880244523b38  EFLAGS: 00010246

[    3.023055] RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010

[    3.023061] RDX: ffff880243d9aff4 RSI: 00000000000080d0 RDI: 0000000000000000

[    3.023068] RBP: ffff8802456271b8 R08: ffff880244523b73 R09: 000000000000aff4

[    3.023074] R10: ffff880243d90000 R11: 000000000000ab2a R12: ffff8802460be000

[    3.023080] R13: ffff880243d9aff4 R14: ffff8802460be000 R15: ffff8802460be000

[    3.023087] FS:  00007ff19f822700(0000) GS:ffff88024ec00000(0000) knlGS:0000000000000000

[    3.023094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

[    3.023099] CR2: 0000000000000010 CR3: 00000002444df000 CR4: 00000000000007f0

[    3.023105] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[    3.023111] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[    3.023118] Process modprobe (pid: 182, threadinfo ffff880244522000, task ffff8802457ea220)

[    3.023124] Stack:

[    3.023128]  ffff880243ced288 0000000000000000 0400080004000800 ffff880243d9aff4

[    3.023138]  ffff880243d9aff4 0000000000000000 0018000000000000 aff4aff401060106

[    3.023147]  0000000000000000 ffff880245627400 ffff8802456271b8 ffff8802460be000

[    3.023157] Call Trace:

[    3.023198]  [<ffffffffa00d73df>] ? radeon_pm_init+0x33f/0x580 [radeon]

[    3.023211]  [<ffffffff81110765>] ? kmem_cache_alloc+0xd5/0xe0

[    3.023248]  [<ffffffffa00a45bd>] ? radeon_modeset_init+0x39d/0xb50 [radeon]

[    3.023285]  [<ffffffffa00aab2c>] ? radeon_ib_ring_tests+0x7c/0xd0 [radeon]

[    3.023318]  [<ffffffffa0081a30>] ? radeon_driver_load_kms+0xe0/0x150 [radeon]

[    3.023330]  [<ffffffff8132d665>] ? drm_get_pci_dev+0x185/0x2c0

[    3.023340]  [<ffffffff812dd1e5>] ? remove_conflicting_framebuffers+0x35/0x60

[    3.023351]  [<ffffffff812aabe8>] ? pci_device_probe+0x98/0xe0

[    3.023360]  [<ffffffff81343798>] ? driver_probe_device+0x68/0x220

[    3.023367]  [<ffffffff813439e3>] ? __driver_attach+0x93/0xa0

[    3.023375]  [<ffffffff81343950>] ? driver_probe_device+0x220/0x220

[    3.023383]  [<ffffffff81341c1d>] ? bus_for_each_dev+0x4d/0x80

[    3.023390]  [<ffffffff81342f08>] ? bus_add_driver+0x178/0x260

[    3.023398]  [<ffffffff81343e04>] ? driver_register+0x84/0x180

[    3.023405]  [<ffffffffa013f000>] ? 0xffffffffa013efff

[    3.023414]  [<ffffffff810002c2>] ? do_one_initcall+0x122/0x170

[    3.023423]  [<ffffffff810a931e>] ? load_module+0x176e/0x1e40

[    3.023430]  [<ffffffff810a5f50>] ? unset_module_init_ro_nx+0x80/0x80

[    3.023438]  [<ffffffff810a9b6d>] ? sys_finit_module+0x8d/0x90

[    3.023448]  [<ffffffff8155c1d2>] ? system_call_fastpath+0x16/0x1b

[    3.023454] Code: 00 49 63 86 14 12 00 00 e9 74 f9 ff ff 31 db 0f 1f 44 00 00 49 63 86 14 12 00 00 83 f8 ff 0f 85 5d f9 ff ff 49 8b 86 f8 11 00 00 <c7> 00 00 00 00 00 49 8b 86 f8 11 00 00 41 c7 86 14 12 00 00 00 

[    3.023514] RIP  [<ffffffffa008617f>] radeon_atombios_get_power_modes+0x6ff/0x830 [radeon]

[    3.023548]  RSP <ffff880244523b38>

[    3.023553] CR2: 0000000000000010

[    3.023560] ---[ end trace 19c019ab61b682ad ]---
```

(I see "remove_conflicting_framebuffers" in there, so I tried disabling efifb and only loading radeon, but that didn't work either.)

----------

## aCOSwt

 *Ant P. wrote:*   

> 
> 
> ```
> [    3.022877] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> ```
> ...

 

It looks like a story totally different from what I was imagining.

The story it now looks like is much older as well as above my league :

```
radeon_modeset_init+0x39d/0xb50 [radeon]
```

Could you disable modesetting ? (boot with nomodeset)

----------

## aCOSwt

 *aCOSwt wrote:*   

>  *Ant P. wrote:*   Okay, looks like I have a problem... 
> 
> Another possible track starts from there : https://lkml.org/lkml/2013/2/21/461
> 
> If you confirm then https://lkml.org/lkml/diff/2013/3/26/661/1 is the patch for correcting the bug.
> ...

 

This patch is not included in upstream's 3.8.7 either.

I talked with Greg K-H who confirms this patch is not included and won't be included as long as there is no formal request for backporting.

=> If you want your problem solved for 3.8 (patches have been commited for 3.9) could you please first confirm if the above mentioned patch solves your boot under UEFI issue or not ?

----------

## ulenrich

@aCOSwt

It is really weird: All along I had these time accounting problems with the BrainFuckScheduler patch and now it is the other way round:

Linux-3.9.0

doesn't have ondemand and very strange times accounted to threads. But the new Bfs-rc patch solves my problems ...

----------

## Ant P.

 *aCOSwt wrote:*   

> => If you want your problem solved for 3.8 (patches have been commited for 3.9) could you please first confirm if the above mentioned patch solves your boot under UEFI issue or not ?

 

I'm OK with ignoring it until 3.9, since I'm not using the GPU on that machine and I seem to be the only -ck user who noticed the breakage anyway.

----------

## ulenrich

 *ulenrich wrote:*   

> @aCOSwt
> 
> It is really weird: All along I had these time accounting problems with the BrainFuckScheduler patch and now it is the other way round:
> 
> Linux-3.9.0
> ...

 I quote myself exceptionally. 

I think I had troubles with changing from Linux-3.8 to 3.9 because

make oldconfig

is broken when major release change happens!?! I have just tried Linux-3.9 from other distributions (Tumbleweed,siduction), which behave correctly. 

Is it officially supported to do "make oldconfig" in this case? Then this my case would be worth a bug ...

----------

## xming

3.9 + ck has been working well here, no crazy times reported by top any more, no issues with make oldconfig here. Just one little issue wit shutdown not actually shutting down, but this is a 3.9.0 issue. Presumably solve by 

```

commit 0d5cadb87e0fa764db7fa0b78d8a6f173cb475a1

Author: Al Viro <viro@zeniv.linux.org.uk>

Date:   Sat May 4 14:40:51 2013 -0400

    do_mount(): fix a leak introduced in 3.9 ("mount: consolidate permission checks")

    

    Cc: stable@vger.kernel.org

    Bisected-by: Michael Leun <lkml20130126@newton.leun.net>

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

```

I have tried it yet.

----------

## kernelOfTruth

 *aCOSwt wrote:*   

>  *kernelOfTruth wrote:*   here's an updated patch: http://pastebin.com/cpqdXZye 
> 
> Thank you but... warning !
> 
> I submitted a patch to Con a couple of weeks ago that looks like... nearly exactly the same as yours...
> ...

 

confirmed ! & thanks for posting the stats

yeah, it made BFS worse

so I stopped using it - it works as a proof of concept 

but needs some tweaking - would be interesting how Con further improves it ...

----------

## aCOSwt

Following BUG 468572 and thanks to Markos Chandras, the ck-sources tree has been updated. 

3.8.3 users should upgrade to 3.8.11,

3.4 users should upgrade to 3.4.43

----------

## thunderrd

Oh, boy.

This is going to make things interesting:

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html

----------

## aCOSwt

 *thunderrd wrote:*   

> Oh, boy.
> 
> This is going to make things interesting:
> 
> http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html

 

Hmmm... again interesting those running 4096 cpus systems ? For sure !

As far as I am personally concerned... Hmmm   :Confused: 

 *Quote:*   

> CPUs running a single task should be able to utilize a maximum amount of CPU power.

 

Situations in which I want the maximum amount of CPU power are more of the kind 4096 tasks competing for getting one core than one core having a single task to run. (Which is by the way why I look for the best performing scheduler. Would I even need a scheduler if each of my cores were running a single task ? and of course, if I get nothing to schedule... isn't it just easy to run full tickless ?)

 *Quote:*   

> A periodic timer tick at HZ=1000 can cause a constant overhead of up to 1.0%. This feature removes that overhead - and speeds up the system by 0.5%-1.0%

 

Ho fine! On an rt-sources system for which I managed to reach a 2µs max reaction time, I am afraid I just cannot afford the hardware needed to accurately and objectively quantify a 20ns gain.

 *Quote:*   

> - A single task executing on a CPU is a pretty common situation, especially with an increasing number of cores/CPUs, so this feature helps desktop and mobile workloads as well.

 

Hmmm... when I consider my personal usage together with my hardware... I just... : smile!

Well... In short, my opinion is that this "enhancement" concerns those systems that get absolutely nothing to schedule.

----------

## ulenrich

 *thunderrd wrote:*   

> Oh, boy.
> 
> This is going to make things interesting:
> 
> http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01831.html

  From above:

 *Quote:*   

> A periodic timer tick at HZ=1000 can cause a constant overhead of up to 1.0%. This feature removes that overhead - and speeds up the system by 0.5%-1.0% 

 Me using:

HZ=300

# CONFIG_NO_HZ

as a non-Gamer. I have 5 times a second the chance to intervene. I have better throughput with far less than HZ_1000 due to a third of the irq provoked context switches. NO_HZ_FULL would speed up the system by 0.3% 

I consider this a NO_HZ _FULL brainfuck  :Smile: Last edited by ulenrich on Mon May 06, 2013 3:14 pm; edited 1 time in total

----------

## Ant P.

That patch might benefit us normal people too - I've encountered a few systems (mostly laptops) where the hardware is so cheap and crappy you can sometimes *hear* the timer at 1kHz.

----------

## ulenrich

 *Ant P. wrote:*   

> you can sometimes *hear* the timer at 1kHz.

 Then why 1kHZ - see above my use of HZ=300.

----------

## aCOSwt

 *ulenrich wrote:*   

>  *Ant P. wrote:*   you can sometimes *hear* the timer at 1kHz. Then why 1kHZ - see above my use of HZ=300.

 

@ulenrich : I still assume that I cannot fully catch Ant P.'s humor because of the language barrier, but I would bet there was an appreciable quantity of it in his contribution.   :Wink: 

If I understand correctly, I agree with Ant P. when he suggests that we would all benefit from crappy systems going down to 0 Hz... because they would of course become less... noisy !   :Very Happy: 

----------

## Ant P.

 *aCOSwt wrote:*   

> I still assume that I cannot fully catch Ant P.'s humor because of the language barrier, but I would bet there was an appreciable quantity of it in his contribution.   

 

There was a bit of that, yeah.  :Smile: 

My netbook really is noisy at times though, considering it has no moving parts except a fan; in a quiet room it makes an audible clicking that corresponds with the wakeup counts I get in powertop, and a busy CPU causes a faint high-pitched whine. My guess is it's caused by RF interference leaking into the speaker circuit.

I have a vague memory of the early 2.6.x days where 1000Hz was recommended against for similar reasons...

----------

## ulenrich

 *Ant P. wrote:*   

> I have a vague memory of the early 2.6.x days where 1000Hz was recommended against for similar reasons...

  These HZ/NO_HZ are interrupts, it isn't the frequency power your cpu is running! It is the chance when you can intervene in programs. May be ten years ago some of these chances could be missed?

When gaming and when your machine is on its limits I also would suggest a lower HZ, because of better troughput !

----------

## thunderrd

Linus is fairly unimpressed, as well:

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01867.html

http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/02292.html

This 'enhancement' (as Eric quite nicely calls it, with tongue firmly in his cheek) to me is far too subtle to care about.  And not only that, it's going to cost Con tons of time fuxoring about to sync up BFS if it happens.  We really don't want that now, do we?

 :Smile: 

----------

## ulenrich

A friction of 1 percentage performance gain at the cost of complicated untested code?

Isn't it what Karl Marx had to say about: At 5% interested, 10% getting hot, over 20% the kapitalist will consider dead bodies ....

----------

## aCOSwt

 *thunderrd wrote:*   

> We really don't want that now, do we?

 

++

 *CK wrote:*   

> It gets tiresome watching the same code being rehashed in many different ways... "because this time we'll do it right".

 

----------

## aCOSwt

Following Bug 469686 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :

- Push the 3.9.2 early release,

- 3.8.13 is also out as last release of the 3.8 stable branch.

- no-networkless {3.6.11-r2 / 3.7.10-r1 / 3.8.3} installs should be upgraded because of a couple of security related issues,

- Please note that 3.4.34 users should upgrade to 3.4.43 for the same reason.

About the 3.9.2 early release, please note that : *CK wrote:*   

> There were some fairly dramatic CPU offline code changes to mainline (YET AGAIN!) and the changes to BFS to make it work were fairly significant so there may once again be issues with power off/reboot/suspend/hibernate.

 

Have already been observed :

- "Strange" output of vmstat after hibernation.

- Hangings on reboot depending on CONFIG_HZ value (getting worse with lower CONFIG_HZ).

----------

## Ant P.

A bit late but it had to be said...

Holy crap, 3.9 is nice! Not only did it fix that radeon problem, it even supports UVD!

----------

## aCOSwt

It Is Alreay Very Expensive to be Fair! => It is going to be even more expensive when being able to tune fairness

I make no doubt that all of us here around reading this thread, are well aware of the fact that ensuring fairness costs a big and highly variable amount of cpu time, this leading to *high* and highly variable latencies. And that it is almost certainly one of the most important reason why we do not want the CFS.

Now, from whatever project's management standpoint, we also know well the now *extreme* cost of offering the possibility for a system to sometimes  :Confused:  more or less  :Confused:  ignore  :Confused:  THE boolean quality / property / characteristic the entire design is based on.

(OK... offering the possibility... without totally ruining the entire system I mean...  :Rolling Eyes:  )

Oh wait! something is still missing in order to completely end the tragedy... the main attraction for the show I mean :

Offering the end user a knob for adjusting a desired percentage of the boolean concept the system is built on !   :Rolling Eyes: 

My post is unfair ? Of course not! It's only 66.6%-fair, which contributes to 50%-granting 99%-eternity to the BFS concept!   :Twisted Evil: 

You want now some 100%-real facts illustrating my 10%-trolling ?

Then welcome to the wake-affine tragedy

BTW, the entire thread is worth reading as renown scheduler devs (Ingo Molnar, Mike Galbraith...) are contributing.

----------

## kernelOfTruth

hm, I remember back in my head that at the beginning when CFS was introduced it was quite good

the longer it existed and the more features got added (to ensure fairness ???)

the more sluggishness I noticed compared to RSDL and/or RFS (or what the previous names were - can't remember anymore since I did a springclean some weeks ago with patchsets, etc.)

so what in essence does this mean ?

currently the kernel is trying very often to ensure fairness which in turn leads to low throughput +/- high latencies ?

----------

## ulenrich

 *Ant P. wrote:*   

> A bit late but it had to be said...
> 
> Holy crap, 3.9 is nice!

  Yes, linux-3.9.4-bfs runs very well! (I didn't use linux-3.8-bfs) And the stable-queue patches for linux-3.8-ff showed a very beta nature of that release compared to linux-3.9 now. I am very pleased  :Smile: 

Time for kernel.org for another new LTS !

----------

## aCOSwt

 *kernelOfTruth wrote:*   

> so what in essence does this mean ?
> 
> currently the kernel is trying very often to ensure fairness which in turn leads to low throughput +/- high latencies ?

 

In essence ? Well... in essence... things are much worse than that.

1/ You get a whole machine rowing in the direction of fairness.

2/ Because you realize that this is not always optimal, you introduce components capable of rowing in the opposite direction.

Fair enough! After all... why not ?

3/ Because rowing in the opposite direction, requires important efforts (overheads), efforts that will sometimes be thankless.

And of course, the result becomes highly workload dependent.

Speaking of these particular components, it is reported that they appear capable of boosting by up to 15% the performances of some workloads while... damaging others by up to... 40%   :Shocked: 

4/ OK then, instead of realizing that the implementation of such a component rowing the opposite direction is an error on principle, you imagine to limit the activity of the component with some kind of timeout and because you cant' know the appropriate value for the threshold (of course... there is no appropriate value) and because it is as easy to implement an umpteen user tuneable as hardcoding a value... you :

Leave to the user the belief he can expect a +15% win, leave to the user the risk to drop everything by 40% and... more probably... to screw everything down by an amount of (15-40)/2 = 12,5% !!!

Funny isn't it ?

Yes... fortunately Mike Galbraith provides sometimes funny images of the reality :  *Quote:*   

> the hardest working load component is the mother of all work, the (singular) server.  Any time 'mom' is not continuously working her little digital a$$ off to keep all those kids fed, you have a performance problem on your hands, the entire load stalls, lives and dies with one and only 'mom'.

 

----------

## ulenrich

I guess the unbeatable fair scheduler takes a hundred percentage of overhead !

----------

## aCOSwt

 *ulenrich wrote:*   

> Time for kernel.org for another new LTS !

 

As long as no one volunteers for maintaining and Greg K-H cannot maintain more than 2 LTS concurrently, I'm afraid you'll have to wait for 3.0's EOL before enjoying a new LTS branch.

That is to say october 2013, in other words... 3.12 ?

----------

## aCOSwt

Following Bug 472842 and thanks to Sergey Popov, the ck-sources tree has been updated in order to :

- Push the 3.9.7 release,

Please note that, as justified in the bug :

- I implemented a very trivial patch in order to prevent users from selecting the "Full dynticks CPU time accounting" AKA CONFIG_VIRT_CPU_ACCOUNTING_GEN kernel configuration option.

How comes that such a considerable amount of people "working on the full dynticks subsystem development" choose the ck-sources package, will remain a mystery to me...   :Rolling Eyes: 

Please also note that from this release, and thanks to the genpatches, the ck-sources offer the BFQ I/O scheduler as a possible choice.

----------

## Ant P.

Wow, I just checked and I've been running deadline on a spinny disk for these past few weeks. Might explain why my browser takes a year to start up...  :Laughing: 

----------

## Ant P.

I've just been looking at the 3.11 radeon drm patches, looks like they finally added a good dynpm implementation. Some of the user replies there suggest it does as good a job as the windows binary driver.

Just in time for summer to have already ended... when I *want* my computer to be a space heater again  :Very Happy: 

----------

## aCOSwt

 *Ant P. wrote:*   

> Just in time for summer to have already ended... when I *want* my computer to be a space heater again 

 

 :Very Happy: 

AFAIK, David Airlie is living in Brisbane...

 :Twisted Evil: 

----------

## thunderrd

Regarding 3.9.7, I have something strange happening.

Here is the relevant section of the dmesg of the 3.9.2 kernel:

```
[    0.000000] Linux version 3.9.2-ck (root@Q6600) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #1 SMP PREEMPT Mon May 27 23:04:48 ICT 2013

[    0.000000] Command line: root=/dev/sda4 rootfstype=ext4 video=uvesafb:1280x1024-32@60,mtrr:3,ywrap 

[    0.000000] KERNEL supported cpus:

[    0.000000]   Intel GenuineIntel

[    0.000000] e820: BIOS-provided physical RAM map:

[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable

[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff6ffff] usable

[    0.000000] BIOS-e820: [mem 0x00000000cff70000-0x00000000cff87fff] ACPI data

[    0.000000] BIOS-e820: [mem 0x00000000cff88000-0x00000000cffcffff] ACPI NVS

[    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001afffffff] usable

[    0.000000] NX (Execute Disable) protection: active

[    0.000000] SMBIOS 2.5 present.

[    0.000000] DMI: System manufacturer System Product Name/P5Q PRO TURBO, BIOS 0602    08/04/2009

[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable

[    0.000000] e820: last_pfn = 0x1b0000 max_arch_pfn = 0x400000000

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000]   00000-9FFFF write-back

[    0.000000]   A0000-BFFFF uncachable

[    0.000000]   C0000-DFFFF write-protect

[    0.000000]   E0000-EFFFF write-through

[    0.000000]   F0000-FFFFF write-protect

[    0.000000] MTRR variable ranges enabled:

[    0.000000]   0 base 1B0000000 mask FF0000000 uncachable

[    0.000000]   1 base 1C0000000 mask FC0000000 uncachable

[    0.000000]   2 base 000000000 mask E00000000 write-back

[    0.000000]   3 base 0D0000000 mask FF0000000 uncachable

[    0.000000]   4 base 0E0000000 mask FE0000000 uncachable

[    0.000000]   5 disabled

[    0.000000]   6 disabled

[    0.000000]   7 disabled

[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

[    0.000000] original variable MTRRs

[    0.000000] reg 0, base: 6912MB, range: 256MB, type UC

[    0.000000] reg 1, base: 7GB, range: 1GB, type UC

[    0.000000] reg 2, base: 0GB, range: 8GB, type WB

[    0.000000] reg 3, base: 3328MB, range: 256MB, type UC

[    0.000000] reg 4, base: 3584MB, range: 512MB, type UC

[    0.000000] total RAM covered: 6144M

[    0.000000] Found optimal setting for mtrr clean up

[    0.000000]  gran_size: 64K    chunk_size: 64K    num_reg: 6     lose cover RAM: 0G

[    0.000000] New variable MTRRs

[    0.000000] reg 0, base: 0GB, range: 2GB, type WB

[    0.000000] reg 1, base: 2GB, range: 1GB, type WB

[    0.000000] reg 2, base: 3GB, range: 256MB, type WB

[    0.000000] reg 3, base: 4GB, range: 2GB, type WB

[    0.000000] reg 4, base: 6GB, range: 512MB, type WB

[    0.000000] reg 5, base: 6656MB, range: 256MB, type WB

[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved

[    0.000000] e820: last_pfn = 0xcff70 max_arch_pfn = 0x400000000

[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576

[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]

[    0.000000]  [mem 0x00000000-0x000fffff] page 4k

[    0.000000] BRK [0x0173f000, 0x0173ffff] PGTABLE

[    0.000000] BRK [0x01740000, 0x01740fff] PGTABLE

[    0.000000] BRK [0x01741000, 0x01741fff] PGTABLE

[    0.000000] init_memory_mapping: [mem 0x1afe00000-0x1afffffff]

[    0.000000]  [mem 0x1afe00000-0x1afffffff] page 2M

[    0.000000] BRK [0x01742000, 0x01742fff] PGTABLE

[    0.000000] init_memory_mapping: [mem 0x1ac000000-0x1afdfffff]

[    0.000000]  [mem 0x1ac000000-0x1afdfffff] page 2M

[    0.000000] init_memory_mapping: [mem 0x180000000-0x1abffffff]

[    0.000000]  [mem 0x180000000-0x1abffffff] page 2M

[    0.000000] init_memory_mapping: [mem 0x00100000-0xcff6ffff]

[    0.000000]  [mem 0x00100000-0x001fffff] page 4k

[    0.000000]  [mem 0x00200000-0xcfdfffff] page 2M

[    0.000000]  [mem 0xcfe00000-0xcff6ffff] page 4k

[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]

[    0.000000]  [mem 0x100000000-0x17fffffff] page 2M

[    0.000000] BRK [0x01743000, 0x01743fff] PGTABLE

[    0.000000] ACPI: RSDP 00000000000fb160 00014 (v00 ACPIAM)

[    0.000000] ACPI: RSDT 00000000cff70000 0003C (v01 A_M_I_ OEMRSDT  08000904 MSFT 00000097)

[    0.000000] ACPI: FACP 00000000cff70200 00084 (v02 A_M_I_ OEMFACP  08000904 MSFT 00000097)

[    0.000000] ACPI: DSDT 00000000cff70440 0AEE4 (v01  A1276 A1276001 00000001 INTL 20060113)

[    0.000000] ACPI: FACS 00000000cff88000 00040

[    0.000000] ACPI: APIC 00000000cff70390 0006C (v01 A_M_I_ OEMAPIC  08000904 MSFT 00000097)

[    0.000000] ACPI: MCFG 00000000cff70400 0003C (v01 A_M_I_ OEMMCFG  08000904 MSFT 00000097)

[    0.000000] ACPI: OEMB 00000000cff88040 00089 (v01 A_M_I_ AMI_OEM  08000904 MSFT 00000097)

[    0.000000] ACPI: HPET 00000000cff7b330 00038 (v01 A_M_I_ OEMHPET  08000904 MSFT 00000097)

[    0.000000] ACPI: OSFR 00000000cff7b370 000B0 (v01 A_M_I_ OEMOSFR  08000904 MSFT 00000097)

[    0.000000] ACPI: Local APIC address 0xfee00000

[    0.000000]  [ffffea0000000000-ffffea0006bfffff] PMD -> [ffff8801a9600000-ffff8801af5fffff] on node 0

[    0.000000] Zone ranges:

[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]

[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]

[    0.000000]   Normal   [mem 0x100000000-0x1afffffff]

[    0.000000] Movable zone start for each node

[    0.000000] Early memory node ranges

[    0.000000]   node   0: [mem 0x00001000-0x0009efff]

[    0.000000]   node   0: [mem 0x00100000-0xcff6ffff]

[    0.000000]   node   0: [mem 0x100000000-0x1afffffff]

[    0.000000] On node 0 totalpages: 1572622

[    0.000000]   DMA zone: 64 pages used for memmap

[    0.000000]   DMA zone: 21 pages reserved

[    0.000000]   DMA zone: 3998 pages, LIFO batch:0

[    0.000000]   DMA32 zone: 13246 pages used for memmap

[    0.000000]   DMA32 zone: 847728 pages, LIFO batch:31

[    0.000000]   Normal zone: 11264 pages used for memmap

[    0.000000]   Normal zone: 720896 pages, LIFO batch:31

[    0.000000] ACPI: PM-Timer IO Port: 0x808

[    0.000000] ACPI: Local APIC address 0xfee00000

[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)

[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])

[    0.000000] IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23

[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)

[    0.000000] ACPI: IRQ0 used by override.

[    0.000000] ACPI: IRQ2 used by override.

[    0.000000] ACPI: IRQ9 used by override.

[    0.000000] Using ACPI (MADT) for SMP configuration information

[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000

[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
```

and here is the 3.9.7 kernel:

```
[    0.000000] Linux version 3.9.7-ck (root@Q6600) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #5 SMP PREEMPT Sun Jul 21 23:08:01 ICT 2013

[    0.000000] Command line: root=/dev/sda4 rootfstype=ext4 video=uvesafb:1280x1024-32@60,mtrr:3,ywrap 

[    0.000000] KERNEL supported cpus:

[    0.000000]   Intel GenuineIntel

[    0.000000] e820: BIOS-provided physical RAM map:

[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable

[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff6ffff] usable

[    0.000000] BIOS-e820: [mem 0x00000000cff70000-0x00000000cff87fff] ACPI data

[    0.000000] BIOS-e820: [mem 0x00000000cff88000-0x00000000cffcffff] ACPI NVS

[    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001afffffff] usable

[    0.000000] NX (Execute Disable) protection: active

[    0.000000] SMBIOS 2.5 present.

[    0.000000] DMI: System manufacturer System Product Name/P5Q PRO TURBO, BIOS 0602    08/04/2009

[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable

[    0.000000] e820: last_pfn = 0x1b0000 max_arch_pfn = 0x400000000

[    0.000000] MTRR default type: uncachable

[    0.000000] MTRR fixed ranges enabled:

[    0.000000]   00000-9FFFF write-back

[    0.000000]   A0000-BFFFF uncachable

[    0.000000]   C0000-DFFFF write-protect

[    0.000000]   E0000-EFFFF write-through

[    0.000000]   F0000-FFFFF write-protect

[    0.000000] MTRR variable ranges enabled:

[    0.000000]   0 base 1B0000000 mask FF0000000 uncachable

[    0.000000]   1 base 1C0000000 mask FC0000000 uncachable

[    0.000000]   2 base 000000000 mask E00000000 write-back

[    0.000000]   3 base 0D0000000 mask FF0000000 uncachable

[    0.000000]   4 base 0E0000000 mask FE0000000 uncachable

[    0.000000]   5 disabled

[    0.000000]   6 disabled

[    0.000000]   7 disabled

[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

[    0.000000] original variable MTRRs

[    0.000000] reg 0, base: 6912MB, range: 256MB, type UC

[    0.000000] reg 1, base: 7GB, range: 1GB, type UC

[    0.000000] reg 2, base: 0GB, range: 8GB, type WB

[    0.000000] reg 3, base: 3328MB, range: 256MB, type UC

[    0.000000] reg 4, base: 3584MB, range: 512MB, type UC

[    0.000000] total RAM covered: 6144M

[    0.000000] *BAD*gran_size: 64K    chunk_size: 64K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 128K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 128K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 512K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 1M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 2M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 4M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 8M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 16M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 32M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 64M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 128M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G

[    0.000000] *BAD*gran_size: 256M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G

[    0.000000]  gran_size: 512M    chunk_size: 512M    num_reg: 4     lose cover RAM: 512M

[    0.000000]  gran_size: 512M    chunk_size: 1G    num_reg: 5     lose cover RAM: 512M

[    0.000000]  gran_size: 512M    chunk_size: 2G    num_reg: 5     lose cover RAM: 512M

[    0.000000]  gran_size: 1G    chunk_size: 1G    num_reg: 3     lose cover RAM: 1G

[    0.000000]  gran_size: 1G    chunk_size: 2G    num_reg: 3     lose cover RAM: 1G

[    0.000000]  gran_size: 2G    chunk_size: 2G    num_reg: 2     lose cover RAM: 2G

[    0.000000] mtrr_cleanup: can not find optimal value

[    0.000000] please specify mtrr_gran_size/mtrr_chunk_size

[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved

[    0.000000] e820: last_pfn = 0xcff70 max_arch_pfn = 0x400000000

[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576

[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]

[    0.000000]  [mem 0x00000000-0x000fffff] page 4k

[    0.000000] BRK [0x0173f000, 0x0173ffff] PGTABLE

[    0.000000] BRK [0x01740000, 0x01740fff] PGTABLE

[    0.000000] BRK [0x01741000, 0x01741fff] PGTABLE

[    0.000000] init_memory_mapping: [mem 0x1afe00000-0x1afffffff]

[    0.000000]  [mem 0x1afe00000-0x1afffffff] page 2M

[    0.000000] BRK [0x01742000, 0x01742fff] PGTABLE

[    0.000000] init_memory_mapping: [mem 0x1ac000000-0x1afdfffff]

[    0.000000]  [mem 0x1ac000000-0x1afdfffff] page 2M

[    0.000000] init_memory_mapping: [mem 0x180000000-0x1abffffff]

[    0.000000]  [mem 0x180000000-0x1abffffff] page 2M

[    0.000000] init_memory_mapping: [mem 0x00100000-0xcff6ffff]

[    0.000000]  [mem 0x00100000-0x001fffff] page 4k

[    0.000000]  [mem 0x00200000-0xcfdfffff] page 2M

[    0.000000]  [mem 0xcfe00000-0xcff6ffff] page 4k

[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]

[    0.000000]  [mem 0x100000000-0x17fffffff] page 2M

[    0.000000] BRK [0x01743000, 0x01743fff] PGTABLE

[    0.000000] ACPI: RSDP 00000000000fb160 00014 (v00 ACPIAM)

[    0.000000] ACPI: RSDT 00000000cff70000 0003C (v01 A_M_I_ OEMRSDT  08000904 MSFT 00000097)

[    0.000000] ACPI: FACP 00000000cff70200 00084 (v02 A_M_I_ OEMFACP  08000904 MSFT 00000097)

[    0.000000] ACPI: DSDT 00000000cff70440 0AEE4 (v01  A1276 A1276001 00000001 INTL 20060113)

[    0.000000] ACPI: FACS 00000000cff88000 00040

[    0.000000] ACPI: APIC 00000000cff70390 0006C (v01 A_M_I_ OEMAPIC  08000904 MSFT 00000097)

[    0.000000] ACPI: MCFG 00000000cff70400 0003C (v01 A_M_I_ OEMMCFG  08000904 MSFT 00000097)

[    0.000000] ACPI: OEMB 00000000cff88040 00089 (v01 A_M_I_ AMI_OEM  08000904 MSFT 00000097)

[    0.000000] ACPI: HPET 00000000cff7b330 00038 (v01 A_M_I_ OEMHPET  08000904 MSFT 00000097)

[    0.000000] ACPI: OSFR 00000000cff7b370 000B0 (v01 A_M_I_ OEMOSFR  08000904 MSFT 00000097)

[    0.000000] ACPI: Local APIC address 0xfee00000

[    0.000000]  [ffffea0000000000-ffffea0006bfffff] PMD -> [ffff8801a9600000-ffff8801af5fffff] on node 0

[    0.000000] Zone ranges:

[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]

[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]

[    0.000000]   Normal   [mem 0x100000000-0x1afffffff]

[    0.000000] Movable zone start for each node

[    0.000000] Early memory node ranges

[    0.000000]   node   0: [mem 0x00001000-0x0009efff]

[    0.000000]   node   0: [mem 0x00100000-0xcff6ffff]

[    0.000000]   node   0: [mem 0x100000000-0x1afffffff]

[    0.000000] On node 0 totalpages: 1572622

[    0.000000]   DMA zone: 64 pages used for memmap

[    0.000000]   DMA zone: 21 pages reserved

[    0.000000]   DMA zone: 3998 pages, LIFO batch:0

[    0.000000]   DMA32 zone: 13246 pages used for memmap

[    0.000000]   DMA32 zone: 847728 pages, LIFO batch:31

[    0.000000]   Normal zone: 11264 pages used for memmap

[    0.000000]   Normal zone: 720896 pages, LIFO batch:31

[    0.000000] ACPI: PM-Timer IO Port: 0x808

[    0.000000] ACPI: Local APIC address 0xfee00000

[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)

[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)

[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])

[    0.000000] IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23

[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)

[    0.000000] ACPI: IRQ0 used by override.

[    0.000000] ACPI: IRQ2 used by override.

[    0.000000] ACPI: IRQ9 used by override.

[    0.000000] Using ACPI (MADT) for SMP configuration information

[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000

[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
```

Note the *BAD*gran_size messages.  I made no changes in the .config from 3.9.2 to 3.9.7; I ran make oldconfig and answered no the the 'NEW" stuff [BFQ and the RTC options].

The memory is good, there is no hardware problem.  I can boot to 3..9.2 with no errors, but 3.9.7, built with the same .config, yields the above.  What else, other then BFQ and the RTC options, could be different and cause the errors?  I can eliminate the errors by manually specifying mtrr gran size and chunk size 512M on the boot line, but it effectively causes loss of use of 500MB of memory, so that is certainly not desirable.

----------

## aCOSwt

 *thunderrd wrote:*   

> Regarding 3.9.7, I have something strange happening.
> 
> Note the *BAD*gran_size messages.  I made no changes in the .config from 3.9.2 to 3.9.7;

 

Could this be kot's troubles related ?

----------

## thunderrd

I'm not sure if it is the same, since I don't know if he was using 3.9.2 previously with no problems.  It does appear to be related, though, and after more research I see that people have been noticing it since 3.9.5.

3.9.7 isn't a must for me, so I guess it would be most prudent to wait for 3.10, since Linus is throwing profanities around to get the code right on that one.   :Smile: 

All kidding aside, it looks like the patches will go into 3.10, so rather than go crazy patching manually, I'll just wait.

----------

## thunderrd

Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch

Then I compiled it with the current options and the error does not exist.  I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.

----------

## aCOSwt

 *thunderrd wrote:*   

> Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch
> 
> Then I compiled it with the current options and the error does not exist.  I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.

 

You mean you downloaded a 3.10.2 ?

If the problem you experimented is the same than the one I had pointed to, nothing abnormal in the fact that 3.10.2 is OK with that. The problem was fixed in 3.10-rc7 and the fix went backported to 3.9.8

As far as gentoo is concerned, 3.4.54 and 3.9.11 should be on their way to portage.

----------

## thunderrd

 *aCOSwt wrote:*   

> 
> 
> You mean you downloaded a 3.10.2 ?
> 
> As far as gentoo is concerned, 3.4.54 and 3.9.11 should be on their way to portage.

 

Eric, yes, it was 3.10.2.

So, if I understand you correctly, gentoo packages >3.9.8 will have the fix.  What is the next planned ck- package?

----------

## aCOSwt

 *thunderrd wrote:*   

> So, if I understand you correctly, gentoo packages >3.9.8 will have the fix.

 

Yes indeed if the problem you faced was the one I had pointed to.

 *thunderrd wrote:*   

> What is the next planned ck- package?

 

As I said 3.4.54 and 3.9.11 are on their way to portage

As far as 3.10 is concerned... mhhh... I have experienced multiple problems with this branch. Mainly ACPI centered.

And considering I do not quite like experiencing ACPI troubles at this time of the year...   :Very Happy: 

Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...

Well...

I'll wait for 3.10.3 before coming back to work on 3.10

----------

## aCOSwt

Following BUG 477916 and thanks to Tom Wijsman, the ck-sources tree has been updated. 

3.9 users should upgrade to 3.9.11,

3.4 users should upgrade to 3.4.54

----------

## ulenrich

 *aCOSwt wrote:*   

> Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...
> 
> Well...
> 
> I'll wait for 3.10.3 before coming back to work on 3.10

 

Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases. In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work. Slowly it then gets included into releases of .1 .2 and .3. But these patches are not anywhere tested at this point. This may lead to the fact the very first stable and tested kernel is a point.six   :Sad:   :Sad:   :Sad:   :Sad:   :Sad:   :Sad: 

I'm following newest kernel releases for quiet a long time now. I would surely get a rich man if I could bet about it: Also if one release gets stable quality at point.five and two out of ten get stable at point.seven or eight, in the long run I won my bet.

----------

## aCOSwt

 *ulenrich wrote:*   

> Isn't it better to wait for 3.10.6 or something? Let me explain...

 

 :Very Happy:   Let me explain : In one word : Holidays!

You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.

I think that the gentoo's sys-kernel/ck-sources is the only package offering high release numbers with the ck patchset. That is it's originality, I leave to others the passion of high version numbers. (no disrespect)

I think that 3.9.2 is the earliest release I have made and this was because I knew that Ant P. needed something to replace his non-working 3.8

This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.

Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I ?

 *ulenrich wrote:*   

> This may lead to the fact the very first stable and tested kernel is a point.six

 

Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...

This probably "because this time we'll do it right".

----------

## TomWij

 *ulenrich wrote:*   

> Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases.

 

As rc versions come packed with new features, releases like .0 can be problematic in terms of stability; after a few releases, quite some patches / fixes have landed to fix the introduced bugs and things become more stable. For this reason, on Gentoo, we stabilize the end of a branch (eg. 3.8.13 stable, 3.9.11 to stabilize very soon); out of branch ends available, the versions near the end of a recent branch look the most stable to us.

 *ulenrich wrote:*   

> In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work.

 

Yes and no; some developers also end up being late with their changes, so they don't make it in time for the rc kernels and rather push things through to stable. They (Linus and Greg) are putting an end to this style.

 *aCOSwt wrote:*   

> You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.

 

Good idea.

 *aCOSwt wrote:*   

> This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.

 

As a heads up (not sure if you follow stable ML), the patches are now under review and test answers are expected by Friday; so, I expect this release to land around Saturday.

 *aCOSwt wrote:*   

> Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I?

 

Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

 *aCOSwt wrote:*   

> Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...
> 
> This probably "because this time we'll do it right".

 

But that's a lot less likely than the way 3.9.2 shows regressions over 3.8.13; the amount of patches on 5 releases is rather minimal, if you calculate the percentage a patch is a regression you'll find maybe one, two, three or four commits or so; most of which only affect some users. Compare that to all the new functionality, rewrites and so on that comes with a 3.9; a lot of regressions are to be find therein, which is what the patches end up dealing with. So, a kernel that really gets things right might be 3.4.54; but then again, perhaps it contains some regressions that only new functionality or a rewrite could solve...

Picking the right kernel version to push / stabilize / run, it's a whole fun debate on its own; there's some agreement and disagreement, I think there are certainly people that would advocate the opposite...

----------

## aCOSwt

 *TomWij wrote:*   

> 
> 
>  *aCOSwt wrote:*   Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I? 
> 
> Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

 

The fact here is that 3.10-ck will... whisper it not... need a local patch.

Of course I know half a dozen of guys capable of taking care of the package for me, but...

Hmmm... how could I say... :

No one of them feel capable of the actually considerable amount of energy usually needed to make a patch find its way to the files directory...   :Wink: 

----------

## thunderrd

Seems to be a problem here:

```
root@Q6600: ~# emerge -avuDN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] x11-proto/videoproto-2.3.2 [2.3.1-r1] ABI_X86="32 (64) (-x32)" 117 kB

[ebuild     U  ] x11-libs/libpciaccess-0.13.2 [0.13.1-r1] USE="zlib -minimal -static-libs" ABI_X86="32 (64) (-x32)" 351 kB

[ebuild  r  U  ] dev-libs/icu-51.2:0/51.2 [51.1:0/51.1] USE="-debug -doc -examples -static-libs" 21,331 kB

[ebuild     U  ] x11-libs/libXfont-1.4.6 [1.4.5-r1] USE="bzip2 ipv6 truetype -doc -static-libs" 478 kB

[ebuild     U  ] dev-libs/nss-3.15.1 [3.15] USE="-utils" 6,140 kB

[ebuild   R    ] x11-misc/xmobar-0.18  USE="alsa dbus -mail -mpd -mpris -threaded -timezone -wifi -xft (-inotify%)" 0 kB

[ebuild  NS    ] sys-kernel/ck-sources-3.9.11:3.9.11 [3.8.3:3.8.3, 3.9.2:3.9.2] USE="-bfsonly -build -deblob -symlink" 302 kB

[ebuild  rR    ] sys-apps/gptfdisk-0.8.6  USE="icu ncurses -static" 0 kB

Total: 8 packages (5 upgrades, 1 in new slot, 2 reinstalls), Size of downloads: 28,715 kB

Would you like to merge these packages? [Yes/No] 

>>> Verifying ebuild manifests

!!! Digest verification failed:

!!! /mnt/ext3_STORAGE/usr/portage/sys-kernel/ck-sources/metadata.xml

!!! Reason: Filesize does not match recorded size

!!! Got: 812

!!! Expected: 0
```

I re-created the manifest with 'ebuild ck-sources-3.9.11.ebuild manifest', and things seem to have straightened out, but I don't know why it happened to begin with.

Just a heads-up, if anyone else has the same trouble.

----------

## aCOSwt

 *thunderrd wrote:*   

> I re-created the manifest with 'ebuild ck-sources-3.9.11.ebuild manifest', and things seem to have straightened out, but I don't know why it happened to begin with.

 

You did right.

Most generally, that sort of error is corrected after re-syncing the portage tree.

----------

## TomWij

No, apparently something did go wrong with that commit; I am not able to pinpoint why, but it recorded the metadata.xml having size 0 for some reason.

 *Quote:*   

> revision 1.345
> 
> date: 2013-07-24 21:41:39 +0200;  author: tomwij;  state: Exp;  lines: +8 -8;  commitid: 533851f02df34567;
> 
> Updated manifest; in the previous commit, the size for metadata.xml somehow got recorded as 0.
> ...

 

So, syncing around an hour from now; that should be resolved, but you can indeed do something like `cd /usr/portage/sys-kernel/ck-sources ; repoman manifest` to fix it up.

----------

## ulenrich

 *ulenrich wrote:*   

> fact the very first stable and tested kernel is a point.six       

 

This time I seemingly loose my bet: 

I just run a recently compiled linux-3.10.3rc1 with BFS enabled - without problems.

But I have disabled nearly all of the newer kernel features ...

@aCOSwt, what patch did you talk about eventually needed?

[edit] Uuups, after 2 hours crashed and totally freezed while heavy duty compiling in a chroot. And I must mention I tainted the kernel using the proprietary nvidia with the inofficial patch ...

----------

## Chiitoo

Teegrins!

Awesome work, Con Kolivas, aCOSwt, et al.  I've been using these sources for quite a while, and they are quite impressive indeed!  Reading about the past of the sources was very interesting, and I am glad that Kolivas returned to it.

Hopefully it wont be as stressful as it seemed to once be (settling to a patch-set is no doubt helping that, or so I'd imagine).

Anyblue, I've come upon some weirdness with the 3.9.11, and wondering now if it's just me (can't find it mentioned anywhere):

```
net/bridge/br_multicast.c: In function ‘br_multicast_del_pg’:

net/bridge/br_multicast.c:272:38: error: ‘struct net_bridge_mdb_entry’ has no member named ‘timer_armed’

make[2]: *** [net/bridge/br_multicast.o] Error 1

make[1]: *** [net/bridge] Error 2

make: *** [net] Error 2
```

Now, I am a complete noob with these things still, but I tried my best to make sense of things as I delved deep into the source code while I also sought the internet for any related information (losing a good portion of the day to being amused by mailing list posts from Torvalds), and came to a conclusion in the end.  Would I be completely off the map if I were to claim that this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7e8e8a8f7a70b343ca1e0f90a31e35ab2d16de1

```
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c

index 19942e3..0daae3e 100644

--- a/net/bridge/br_mdb.c

+++ b/net/bridge/br_mdb.c

@@ -447,7 +447,7 @@ static int __br_mdb_del(struct net_bridge *br, struct br_mdb_entry *entry)

       call_rcu_bh(&p->rcu, br_multicast_free_pg);

       err = 0;

 

-      if (!mp->ports && !mp->mglist &&

+      if (!mp->ports && !mp->mglist && mp->timer_armed &&

           netif_running(br->dev))

          mod_timer(&mp->timer, jiffies);

       break;

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c

index 81befac..69af490 100644

--- a/net/bridge/br_multicast.c

+++ b/net/bridge/br_multicast.c

@@ -270,7 +270,7 @@ static void br_multicast_del_pg(struct net_bridge *br,

       del_timer(&p->timer);

       call_rcu_bh(&p->rcu, br_multicast_free_pg);

 

-      if (!mp->ports && !mp->mglist &&

+      if (!mp->ports && !mp->mglist && mp->timer_armed &&

           netif_running(br->dev))

          mod_timer(&mp->timer, jiffies);
```

has been back-ported, but the cause has not:http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f00b2e7cf241fa389733d41b6

```
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c

index 2475147..40bda80 100644

--- a/net/bridge/br_multicast.c

+++ b/net/bridge/br_multicast.c

@@ -617,8 +617,6 @@ rehash:

 

    mp->br = br;

    mp->addr = *group;

-   setup_timer(&mp->timer, br_multicast_group_expired,

-          (unsigned long)mp);

 

    hlist_add_head_rcu(&mp->hlist[mdb->ver], &mdb->mhash[hash]);

    mdb->size++;

@@ -656,7 +654,6 @@ static int br_multicast_add_group(struct net_bridge *br,

    struct net_bridge_mdb_entry *mp;

    struct net_bridge_port_group *p;

    struct net_bridge_port_group __rcu **pp;

-   unsigned long now = jiffies;

    int err;

 

    spin_lock(&br->multicast_lock);

@@ -671,7 +668,6 @@ static int br_multicast_add_group(struct net_bridge *br,

 

    if (!port) {

       mp->mglist = true;

-      mod_timer(&mp->timer, now + br->multicast_membership_interval);

       goto out;

    }

 

@@ -679,7 +675,7 @@ static int br_multicast_add_group(struct net_bridge *br,

         (p = mlock_dereference(*pp, br)) != NULL;

         pp = &p->next) {

       if (p->port == port)

-         goto found;

+         goto out;

       if ((unsigned long)p->port < (unsigned long)port)

          break;

    }

@@ -690,8 +686,6 @@ static int br_multicast_add_group(struct net_bridge *br,

    rcu_assign_pointer(*pp, p);

    br_mdb_notify(br->dev, port, group, RTM_NEWMDB);

 

-found:

-   mod_timer(&p->timer, now + br->multicast_membership_interval);

 out:

    err = 0;

 

@@ -1131,6 +1125,10 @@ static int br_ip4_multicast_query(struct net_bridge *br,

    if (!mp)

       goto out;

 

+   setup_timer(&mp->timer, br_multicast_group_expired, (unsigned long)mp);

+   mod_timer(&mp->timer, now + br->multicast_membership_interval);

+   mp->timer_armed = true;

+

    max_delay *= br->multicast_last_member_count;

 

    if (mp->mglist &&

@@ -1205,6 +1203,10 @@ static int br_ip6_multicast_query(struct net_bridge *br,

    if (!mp)

       goto out;

 

+   setup_timer(&mp->timer, br_multicast_group_expired, (unsigned long)mp);

+   mod_timer(&mp->timer, now + br->multicast_membership_interval);

+   mp->timer_armed = true;

+

    max_delay *= br->multicast_last_member_count;

    if (mp->mglist &&

        (timer_pending(&mp->timer) ?

@@ -1263,7 +1265,7 @@ static void br_multicast_leave_group(struct net_bridge *br,

          call_rcu_bh(&p->rcu, br_multicast_free_pg);

          br_mdb_notify(br->dev, port, group, RTM_DELMDB);

 

-         if (!mp->ports && !mp->mglist &&

+         if (!mp->ports && !mp->mglist && mp->timer_armed &&

              netif_running(br->dev))

             mod_timer(&mp->timer, jiffies);

       }

@@ -1275,30 +1277,12 @@ static void br_multicast_leave_group(struct net_bridge *br,

            br->multicast_last_member_interval;

 

    if (!port) {

-      if (mp->mglist &&

+      if (mp->mglist && mp->timer_armed &&

           (timer_pending(&mp->timer) ?

            time_after(mp->timer.expires, time) :

            try_to_del_timer_sync(&mp->timer) >= 0)) {

          mod_timer(&mp->timer, time);

       }

-

-      goto out;

-   }

-

-   for (p = mlock_dereference(mp->ports, br);

-        p != NULL;

-        p = mlock_dereference(p->next, br)) {

-      if (p->port != port)

-         continue;

-

-      if (!hlist_unhashed(&p->mglist) &&

-          (timer_pending(&p->timer) ?

-           time_after(p->timer.expires, time) :

-           try_to_del_timer_sync(&p->timer) >= 0)) {

-         mod_timer(&p->timer, time);

-      }

-

-      break;

    }

 

 out:

@@ -1674,6 +1658,7 @@ void br_multicast_stop(struct net_bridge *br)

       hlist_for_each_entry_safe(mp, n, &mdb->mhash[i],

                  hlist[ver]) {

          del_timer(&mp->timer);

+         mp->timer_armed = false;

          call_rcu_bh(&mp->rcu, br_multicast_free_group);

       }

    }

diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h

index e260710..1b0ac95 100644

--- a/net/bridge/br_private.h

+++ b/net/bridge/br_private.h

@@ -112,6 +112,7 @@ struct net_bridge_mdb_entry

    struct timer_list      timer;

    struct br_ip         addr;

    bool            mglist;

+   bool            timer_armed;

 };

 

 struct net_bridge_mdb_htable
```

I figured the error message makes sense since the “timer_armed” doesn't seem to exist at all.  The sources indeed build after reverting the commit: c7e8e8a8f7a70b343ca1e0f90a31e35ab2d16de1

Perhaps my kernel configuration is just out of whack, but this really seems wrong to me.  ^^;

Again, thank you, and I would appreciate if someone wiser could confirm and/or point me my error(s)!

----------

## aCOSwt

 *Chiitoo wrote:*   

> Anyblue, I've come upon some weirdness with the 3.9.11, and wondering now if it's just me (can't find it mentioned anywhere):

 

It's actually... not just you!

 *Chiitoo wrote:*   

> Would I be completely off the map if I were to claim that this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7e8e8a8f7a70b343ca1e0f90a31e35ab2d16de1
> 
> has been back-ported

 

And is responsible for the problem you experience. You are correct.

I'll make my best to push a ck-sources-3.9.11-r1 (in wich this patch will have been removed) before tonight.

In the mean time, if you are in a hurry, you can :

1/ #cp ck-sources-3.9.11.ebuild ck-sources-3.9.11-r1.ebuild

2/ Edit the ck-sources-3.9.11-r1.ebuild and change the line reading K_GENPATCHES_VER="16" against K_GENPATCHES_VER="17"

3/ Save and exit

4/ #repoman manifest

Then emerge this package.

----------

## SayusiAndo

Hi All,

When I want to compile the ck-sources-3.9.11 using genkernel - it is comfortable for me - then I got the errors below:

```

configuration written to .config

*** End of the configuration.

*** Execute 'make' to start the build or try 'make help'.

*         >> Compiling 3.9.11-ck bzImage...

*         >> Not installing firmware as it's included in the kernel already (CONFIG_FIRMWARE_IN_KERNEL=y)...

*         >> Compiling 3.9.11-ck modules...

* ERROR: Failed to compile the "modules" target...

*

* -- Grepping log... --

*

*  SHIPPED scripts/kconfig/zconf.lex.c

*  SHIPPED scripts/kconfig/zconf.hash.c

*  HOSTCC  scripts/kconfig/zconf.tab.o

*  HOSTLD  scripts/kconfig/conf

*scripts/kconfig/conf --oldconfig Kconfig

*.config:407:warning: symbol value 'm' invalid for ACPI_CONTAINER

*.config:2863:warning: symbol value 'm' invalid for RTC_LIB

*.config:2864:warning: symbol value 'm' invalid for RTC_CLASS

```

Should I attach the full genkernel log? It is huge...

----------

## aCOSwt

 *SayusiAndo wrote:*   

> When I want to compile the ck-sources-3.9.11 using genkernel - it is comfortable for me - then I got the errors below

 

 :Confused:  I am very sorry : I know absolutely nothing of genkernel.   :Embarassed: 

I'd suggest you open a new thread with your question, so that should attract the attention of genkernel's gurus (JRG, NeddySeagoon...)

----------

## SayusiAndo

 *aCOSwt wrote:*   

>  *SayusiAndo wrote:*   When I want to compile the ck-sources-3.9.11 using genkernel - it is comfortable for me - then I got the errors below 
> 
>  I am very sorry : I know absolutely nothing of genkernel.  
> 
> I'd suggest you open a new thread with your question, so that should attract the attention of genkernel's gurus (JRG, NeddySeagoon...)

 

There is no problem at all. Btw, I should try it manually, but I'm a lazy human...  :Smile:  I'll do accordingly.

----------

## kernelOfTruth

this thread is about choice + ck stuff

so I figured the following might be interesting:

http://marc.info/?l=linux-kernel&m=137521302202537&w=2

latency cut-down by 80%   :Exclamation: 

it's still RFC - so let's see how it develops ...

BFQ occassionally tends to hardlock for me - seems like they haven't found the cause yet   :Sad: 

so I'll meanwhile use CFQ instead ...

----------

## SayusiAndo

Hi Guys,

I got this error message when I want to compile ck-kernel-3.9.11 without genkernel.

```

sayusi-desktop linux # make

make[1]: Nothing to be done for `all'.

make[1]: Nothing to be done for `relocs'.

  CHK     include/generated/uapi/linux/version.h

  CHK     include/generated/utsrelease.h

  CALL    scripts/checksyscalls.sh

  CC      scripts/mod/devicetable-offsets.s

  GEN     scripts/mod/devicetable-offsets.h

  HOSTCC  scripts/mod/file2alias.o

  HOSTLD  scripts/mod/modpost

  CHK     include/generated/compile.h

make[3]: `arch/x86/realmode/rm/realmode.bin' is up to date.

  CHK     kernel/config_data.h

  CC [M]  net/bridge/br_multicast.o

net/bridge/br_multicast.c: In function ‘br_multicast_del_pg’:

net/bridge/br_multicast.c:272:38: error: ‘struct net_bridge_mdb_entry’ has no member named ‘timer_armed’

make[2]: *** [net/bridge/br_multicast.o] Error 1

make[1]: *** [net/bridge] Error 2

make: *** [net] Error 2

sayusi-desktop linux # eselect kernel list

Available kernel symlink targets:

  [1]   linux-3.9.7-ck

  [2]   linux-3.9.11-ck *

  [3]   linux-3.10.3-gentoo-r1

  [4]   linux-3.10.4-gentoo

sayusi-desktop linux #

```

Any suggestion what should I do? What information is needed for you guys to figure out what the problem is?

----------

## aCOSwt

 *SayusiAndo wrote:*   

> Any suggestion what should I do? What information is needed for you guys to figure out what the problem is?

 

Please read my answer to Chiitoo, 6 posts above.

I must apologize as I still did not push the 3.9.11-r1 as promised. I have been bothered by a MySQL upgrade then 3.10.3 and 4 came quickly... with their loads of problems...

Act as I suggested to Chiitoo or... be patient.

----------

## SayusiAndo

 *aCOSwt wrote:*   

>  *SayusiAndo wrote:*   Any suggestion what should I do? What information is needed for you guys to figure out what the problem is? 
> 
> Please read my answer to Chiitoo, 6 posts above.
> 
> I must apologize as I still did not push the 3.9.11-r1 as promised. I have been bothered by a MySQL upgrade then 3.10.3 and 4 came quickly... with their loads of problems...
> ...

 

Ahh, thank you very much!

----------

## aCOSwt

3.9.11-r1 and 3.10.4 are on their way

----------

## SayusiAndo

 *aCOSwt wrote:*   

> 3.9.11-r1 and 3.10.4 are on their way

 

Rispect maximus!

----------

## Ant P.

The 3.11-ck1 patch's out as of yesterday.

----------

## thunderrd

Yup.  3.11/BFS 0.442

From IRC:

 *Quote:*   

> Topic for 22#ck is: http://ck-hack.blogspot.com ; Latest -ck: 3.11-ck1 | http://kernel.kolivas.org | lrzip 0.616 http://lrzip.kolivas.org | latest BFS: 0.442

 

and:

http://ck-hack.blogspot.com/2013/09/bfs-0441-311-ck1.html

----------

## ulenrich

I made a backport of bfs-442

for use with LTS kernel Linux-3.10:

3.10-sched-bfs-442-new.patch

Found in attachement of bug

https://bugs.gentoo.org/show_bug.cgi?id=487362

----------

## PaulBredbury

 *ulenrich wrote:*   

> 3.10-sched-bfs-442-new.patch

 

Thanks, it seems to be running OK   :Smile: 

I was interested in the new check for throttling:

 *Quote:*   

> The other significant change is to check for throttled CPUs when choosing an idle CPU to move a process to, which should impact the behaviour and possibly throughput when using a scaling CPU governor, such as ondemand.

 

For (hopefully) convenience, here's a diff from BFS 440 to your 442, created by applying both to vanilla kernel 3.10.15.

Edit: And here's Alfred Chen's patch, in proper format.Last edited by PaulBredbury on Wed Oct 09, 2013 11:29 am; edited 1 time in total

----------

## ulenrich

@Paul, three hours later than me at ck-hack.blogspot.com "Alfred Chen" showd a patch where he relocated mutex_lock and mutex_unlock. What do you think of it:

Alfred Chen puts the

mutex_lock (respective mutex_unlock)

outside of 

for_each_online_cpu(cpu)

If mutex_lock is meant for one cpu

this sound reasonable? Is it?

----------

## PaulBredbury

Alfred Chen's patch runs OK too - that's about all I'm qualified to say.

I kinda noticed a hang at startup, a couple of times with kernel 3.10 & BFS, but it coincided with me playing with kernel & ACPI settings, so I can't reproduce it for a proper test.

----------

## PaulBredbury

And here's another patch for improved ondemand (main patch).

So, to recap, the patches to apply to kernel 3.10.x are:

BFS 442

Alfred Chen's mutex patch

This ondemand recalc patch

It's all working stably for me.

Edit on 20140109: kernel 3.10.26 had a trivial change, causing these patches to need refreshing. Here's those 3 patches, merged into 1 patch to apply to kernel 3.10.26  :Smile: Last edited by PaulBredbury on Thu Jan 09, 2014 11:56 pm; edited 1 time in total

----------

## ulenrich

@Paul +1 

Yes runs well for me.  But

There is a BFS patch of

+#define DEF_FREQUENCY_UP_THRESHOLD     (63)

For me the ondemand patch runs better with the original value

-#define DEF_FREQUENCY_UP_THRESHOLD     (80)

The  DEF_FREQUENCY_DOWN_DIFFERENTIAL value was obosleted anyway...

Should we ask Con Kolivas to outsource the patching of

drivers/cpufreq/cpufreq_ondemand.c

into the ck1 patchset?

----------

## PaulBredbury

It's just a default. I go in the opposite direction, to keep gaming smooth:

```
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
```

----------

## thunderrd

@aCOSwt:

Is there any hope that there will be further updates, or are we now stalled at 3.9?  Things have been pretty silent here.

I saw the problems in Bug #479382, and am thinking maybe you have had enough proxy maintaining   :Smile: 

I, for one, appreciate all that you have done, Eric.  Thank you.

----------

## aCOSwt

 *thunderrd wrote:*   

> Is there any hope that there will be further updates

 

I hope so

 *thunderrd wrote:*   

> Things have been pretty silent here.

 

I agree and must acknowledge that 25% of the reasons of the silence is on my full and entire responsibility.

Don't ask me to distribute the 75 other %, to each is own!

 *thunderrd wrote:*   

>  I saw the problems in Bug #479382, and am thinking maybe you have had enough proxy maintaining

 

Not really. The idea of proxy maintaining perfectly fits my purpose.

When there is a will, there is a way. And I think that until the Bug you mention, we have both (proxy-maintainers and I) fruitfully managed to find one.

I must acknowledge with Bug #479382 a lack of good will from my own side.

Several reasons triggered it: the poor performances of 3.9, 3.10 kernels is one of them, the nvidia mess is another one, "upstream" reactivity a third, ... a fourth...

In such conditions, v.g : I am not myself convinced that the final result is worth it, I admit that fighting / arguing with the proxy-maintainers about a silly-stupid-trivial patch is well above my forces.

 *thunderrd wrote:*   

> I, for one, appreciate all that you have done, Eric.  Thank you.

 

Thank you for saying this.

But... be aware that... I am for absolutely nothing in the actually best performing ck-sources kernel release available in portage, hmmm... the best performing kernel release available in portage!   :Wink: 

OK, then, practically :

- I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47

- I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels)

- I expect being capable to push 3.10 and 3.11 during week 48.

If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards, I'll require a slot to be opened in gentoo-sunrise.

Thank you, thunderrd, for your support.

----------

## TomWij

 *aCOSwt wrote:*   

> - I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47

 

That is four months old by now, EOL and insecure; is this still worth pursuing?

 *aCOSwt wrote:*   

> - I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels)

 

Definitely worth it for people hit by the changes in the later kernels.

 *aCOSwt wrote:*   

> - I expect being capable to push 3.10 and 3.11 during week 48.

 

Sounds good; please note that I have made a forward ported patch for 3.12 some time ago if we want to add more support, I'll probably test this patch more thoroughly soon.

 *aCOSwt wrote:*   

> If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards

 

Feel free to explain why these patches are needed and I'll look into it.

----------

## aCOSwt

 *TomWij wrote:*   

>  *aCOSwt wrote:*   - I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47 
> 
> That is four months old by now, EOL and insecure; is this still worth pursuing?

 

It's not me who wrote *Quote:*   

> # For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
> 
> # as some of them experience problems with the new stable kernel 3.10.7;

 

But... I... quite agree with that.

In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution.

BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.

Of course this is only my opinion as far as I am concerned.

Nevermind anyway.

However, I do not know how you expect the following snippet of code to be working

```
            for j in ${KPATCH_DIR}/*/50*_*.patch*; do

                if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then

                    UNIPATCH_DROP+=" $(basename ${j})"

                fi

            done
```

I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)

But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally.

----------

## TomWij

 *aCOSwt wrote:*   

> It's not me who wrote *Quote:*   # For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
> 
> # as some of them experience problems with the new stable kernel 3.10.7; 
> 
> But... I... quite agree with that.

 

Well, yeah, I think we're quite close to dropping that.

 *aCOSwt wrote:*   

> In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution.

 

True, but an overlay / local ebuild might fit the purpose better; and isn't this something that can be forward ported? If you really want it, go ahead, alternative kernel sources aren't considered supported by Gentoo Security; it is just a suggestion to avoid affecting users and/or receiving blame.

 *aCOSwt wrote:*   

> BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.

 

You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.

And when you want to instead define your own USE flag gentoo-experimental you can have it set K_EXP_GENPATCHES_LIST="*" when calling the unpack function; note that you need to set K_EXP_GENPATCHES_PULL or override SRC_URI if you do so, because due to Portage's limitations we can't export a variable to control the USE flag name.

 *aCOSwt wrote:*   

> However, I do not know how you expect the following snippet of code to be working
> 
> ```
>             for j in ${KPATCH_DIR}/*/50*_*.patch*; do
> 
> ...

 

Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code...

----------

## aCOSwt

 *TomWij wrote:*   

>  *aCOSwt wrote:*   BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes. 
> 
> You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.

 

I understand that but if you want the genpatches experimental tarball and have the ck-sources experimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches.

 *TomWij wrote:*   

>  *aCOSwt wrote:*   However, I do not know how you expect the following snippet of code to be working
> 
> ```
>             for j in ${KPATCH_DIR}/*/50*_*.patch*; do
> 
> ...

 

Well, having K_EXP_GENPATCHES_LIST initialized the way I (&& hardened) would initialize UNIPATCH_EXCLUDE, I mean, something of the kind

```
K_EXP_GENPATCHES_LIST="

    5000_BFQ-1-block-cgroups-kconfig-build-bits-for-v6r2-3.10.patch

    5000_BFQ-2-block-introduce-the-v6r2-I-O-sched-for-3.10.patch1

    5000_BFQ-3-block-add-Early-Queue-Merge-EQM-v6r2-I-O-sched-for-3.10.patch1

    5000_BFQ-4-block-Switch-from-v6r2-for-3.10.0-v6r2-for-3.10.patch"
```

Does not work for me.

BTW, having K_EXP_GENPATCHES_LIST="*" as you suggest, does not work either.

Only having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally actually does the trick.

----------

## TomWij

 *aCOSwt wrote:*   

>  *TomWij wrote:*    *aCOSwt wrote:*   BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes. 
> 
> You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag. 
> 
> I understand that but if you want the genpatches experimental tarball and have the ck-sources experimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches.

 

All its occurences are guarded by -z ${K_EXP_GENPATCHES_NOUSE} which means that the USE flag is only checked if you not set that; thus, if you set it, the eclass won't check the USE flag.

 *aCOSwt wrote:*   

>  *TomWij wrote:*    *aCOSwt wrote:*   However, I do not know how you expect the following snippet of code to be working
> 
> ```
>             for j in ${KPATCH_DIR}/*/50*_*.patch*; do
> 
> ...

 

UNIPATCH_EXCLUDE is for the user.

 *aCOSwt wrote:*   

> BTW, having K_EXP_GENPATCHES_LIST="*" as you suggest, does not work either.
> 
> Only having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally actually does the trick.

 

Hmm, this indeed behaves odd, will investigate further.

----------

## TomWij

Okay, my bad, you have found a bug; thank you very much, this is fixed now.

 *Quote:*   

> +  18 Nov 2013; Tom Wijsman <TomWij@gentoo.org> kernel-2.eclass:
> 
> +  Reimplemented K_EXP_GENPATCHES_LIST patch matching by switching the LHS with
> 
> +  the RHS and doing much more proper matching (50 works, *_BFQ-* works,
> ...

 

```
-            if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then

-               UNIPATCH_DROP+=" $(basename ${j})"

-            fi

+            for k in ${K_EXP_GENPATCHES_LIST} ; do

+               [[ "$(basename ${j})" == ${k}* ]] && continue 2

+            done

+            UNIPATCH_DROP+=" $(basename ${j})"

```

Sorry, my testing appears to have been improper on this variable; I'm not particularly good at Bash, but the above diff (replaced lines with - by +) should do fine as far as I can see in new tests.

----------

## thunderrd

FWIW, and in case you don't already know, Con has:

patch-3.12-ck1.bz2

and

3.12-sched-bfs-443.patch

available in his server now.

----------

## aCOSwt

 :Embarassed:  *** Inadvertently reedited ****  :Embarassed: 

----------

## aCOSwt

- And I forgot telling that from 3.8, following a discussion I had with him on IRC, Con removed from the ck-patchset a couple of patches aiming at reducing the apparent IO throughput, in particular through extremely low settings of the dirty ratios.

These ratios are now back to default, which means that IO-bound tasks are now CPU-bound for much longer than usual.

This may well explain why some of you might well, since 3.8, feel their system less interactive during heavy disk write operations.

Those wishing to restore pre-3.8 behaviour can

```
#echo 1 > /proc/sys/vm/dirty_background_ratio

#echo 1 > /proc/sys/vm/dirty_ratio
```

To be done after having entered your preferred DE as it is very likely to fiddle these values when initializing.

- And I of course also forgot to urge you to keep away from the following kernel config settings :

RCU_USER_QS

RCU_NOCB_CPU

----------

## aCOSwt

Following BUG 492966, and thanks to Tom Wijsman the ck-sources tree has been updated. 

3.11 users should upgrade to 3.11.10,

3.12 users should upgrade to 3.12.2

Note about 3.12.2 : ck-patched kernels have always been concerned with random suspend/resume issues.

This is even more true since 3.9 and the "dramatic CPU offline code changes to mainline"

Con tried to address these issues with several patches, among which the bfs443-hibernate_test2.patch.

The idea grounding this patch is affining tasks to CPU0 as CPUs go offline.

The experimental use flag is back in the ck-sources together with a new use flag named hibernate.

emerging the ck-sources-3.12.2 with both use flags set will apply the above patch to bfs.

 :Embarassed:  OK, OK... I know... BFS-444 is out today... this making my initiative... obsolete!   :Rolling Eyes: 

But... 444 was not even planned when I posted my bump request last week.

I should push it as part of 3.12.3

----------

## aCOSwt

Following BUG 494234, and thanks to Tom Wijsman, the ck-sources tree has been updated. 

3.4 users should upgrade to 3.4.74,

3.10 users should upgrade to 3.10.24,

3.12 users can upgrade to 3.12.5 and test the new bfs-444 successfully addressing several suspend/resume issues.

----------

## aCOSwt

Following BUG 502442, and thanks to Tom Wijsman, the ck-sources tree has been updated. 

3.4 users should upgrade to 3.4.82,

Be aware that a new custom patch is being applied with this release.

Without it, the build of the kernel would fail because of an unresolved reference.

Since 3.4.81, linux defines a new function which is of absolutely no use to bfs.

(It does not concern security either, it is nothing but yet another pathetic try for the cfs to catch some idea of the cpu load when working tickless)

However, this function is declared external in the sched.h header used by bfs.

=> The trivial patch simply adds a void definition of that function in the rightly named compatibility crap section of the bfs.c code.

----------

## kernelOfTruth

 ck-patchset for 3.13 kernel series is out 

and immediately the computer feels like it's 2 generations younger   :Laughing: 

evaluating now under heavy CPU load and memory pressure against heavily patched up 3.13  kernel to 3.14 CFS (wasn't working not quite bad but still sluggishness was there, 8 GB zram, ZFS mirror1, Btrfs w. compression (lzo) on root)

----------

## aCOSwt

 *kernelOfTruth wrote:*   

>  ck-patchset for 3.13 kernel series is out 

 

And even more that what's just apparent

ha bha!   :Evil or Very Mad: 

For the first time in the ck-sources' life, gentoo-ck-sources could even have been the first to offer a ck-patched kernel...

I just apparently... failed!

Ha bha!   :Evil or Very Mad: 

BTW, seems to get a couple of trouble under kvm.

----------

## kernelOfTruth

@aCOSwt:

don't be so hard on yourself   :Smile: 

hopefully virtualbox isn't affected as well

----------

## aCOSwt

Following BUG 503142, and thanks to Tom Wijsman, the ck-sources tree has been updated. 

3.10 users should upgrade to 3.10.32,

3.12 users should upgrade to 3.12.13,

Be aware that the 3.12 branch shows a regression in the handling of usbatm debug traces, so those who get CONFIG_USB_ATM are concerned.

3.13.5 was also made available.

Be aware that, despite a relatively high release number, 3.13.5 is an early release of the ck-sources => It is likely to show a couple of problems.

In particular the fact that it breaks kvm seems confirmed.

 *kernelOfTruth wrote:*   

> @aCOSwt:don't be so hard on yourself   

 

 :Smile: 

I first tried to be hard on others... it does not work well either...   :Twisted Evil: 

----------

## Chiitoo

Many thanks.  Just booted 3.13.5 on my main-machine.

Be aware of that, you also helped me solve a couple of issues on a laptop I am testing things currently.  For whatever reason, X did not want to see the device it should have been using with the i915-driver, while vesa worked.  I had also some trouble getting terminal emulators to work.

Yes, both were something something /dev something related issues, but I had no real clues where to look at, or what.  This is no surprise, because, before someone screams udev, I'll just say:

static-dev

Lo, and behold, everything just worked with the new(er) kernel.  It's embarrassingly a case of not sure what I did, but that fixed it!

Must.  Find.  Reason.

Anyblue!

Thanks!   :Cool: 

----------

## aCOSwt

Following BUG 508768, and thanks to Markos Chandras, the ck-sources tree has been updated. 

3.13 users should upgrade to 3.13.11,

That release should no longer break kvm.

----------

## aCOSwt

Following BUG 509930, and thanks to Markos Chandras, the ck-sources tree has been updated. 

3.4 users should upgrade to 3.4.89,

3.10 users should upgrade to 3.10.39,

3.12 users should upgrade to 3.12.19,

The regression in the handling of usbatm debug traces with the 3.12 series went fixed in 3.12.19

3.14.3 was also made available.

----------

## Perfect Gentleman

please, update to 3.14.4

----------

## aCOSwt

 *Perfect Gentleman wrote:*   

> please, update to 3.14.4

 

Being said that I am working on updates but was more targetting a 3.14.5 than a 3.14.4, I am interested to know more about your reasons for this. Security fix ? Any particular driver / feature bug fix ? As well as the level of urgency. Depending on that, I could be able to suggest a temporary workaround.

----------

## Perfect Gentleman

yep, security issues that were fixed with 3.14.4 patch.

----------

## TomWij

Yes, https://bugs.gentoo.org/show_bug.cgi?id=CVE-2014-0196 for which upstream has recently released fixes for in most versions; apart from 3.13.11 which is EOL, as well as 2.6.32.61 which is almost a year old.

----------

## aCOSwt

Tom, weren't you supposed to be devaway this week end ?   :Wink: 

OK... had just asked because, strictly speaking, sys-kernel/ck-sources unequivocally states : 

```
 WARN: postinst

ck-sources is UNSUPPORTED by Gentoo Security.

This means that it is likely to be vulnerable to recent security issues.
```

It is the very first time I get a bump request for security fixes.

Nevermind. I won't refuse helping a Perfect Gentelman having apparently registred here in the first intention to get the best *-sources money can't buy.

(Even if 3.14.4 is... actually not the best release!... yet!)

Will do the necessary testings tonight and post the ebuild(s) tomorrow.

----------

## Perfect Gentleman

aCOSwt, honestly speaking, i've been using ck-kernel for a long time in Arch_Linux. So far my parents' desktop and microserver still run it.

----------

## aCOSwt

 *Perfect Gentleman wrote:*   

> please, update to 3.14.4

 

Done.

If you can't wait for the commit, you can download the attached ebuild from the abovementioned link, or there : https://510800.bugs.gentoo.org/attachment.cgi?id=377258 then

repoman manifest and emerge.

----------

## Perfect Gentleman

why do gentoo-sources use old version of BFQ ?

----------

## kernelOfTruth

 *Perfect Gentleman wrote:*   

> why do gentoo-sources use old version of BFQ ?

 

file a bug-report   :Very Happy: 

----------

## thunderrd

@aCOSwt, FYI, should you be interested - 

This on IRC around 6AM GMT today:

 *Quote:*   

> conman: hekel, patch seems stable
> 
> conman: will release tonight as is
> 
> hekel: yep, same here.. no issues on 3.15.2 and 3.15.3

 

Con has pretty much said that BFS is done in development, that he is completely satisfied with it [BFS/ck] at this point.

----------

## _Nomad_

Any plans on releasing an updated ebuild for 3.16 ?

----------

## Perfect Gentleman

there are another sources with ck-patches like geek/pf/liquorix-sources

----------

## Polyatomic

 *_Nomad_ wrote:*   

> Any plans on releasing an updated ebuild for 3.16 ?

 

Patch up manually   :Very Happy: 

```
System uname: Linux-3.16.2-ck2+-x86_64-AMD_FX-tm-9590_Eight-Core_Processor-with-gentoo-2.2

KiB Mem:    16329860 total,  15630228 free

KiB Swap:          0 total,         0 free

Timestamp of tree: Sun, 05 Oct 2014 10:15:01 +0000

```

Flys man ...Last edited by Polyatomic on Tue Oct 07, 2014 5:27 am; edited 1 time in total

----------

## thunderrd

@polyatomic

Which source package did you use?  Vanilla?

----------

## Perfect Gentleman

ck-sources = gentoo-sources + ck-patches

----------

## Polyatomic

 *thunderrd wrote:*   

> @polyatomic
> 
> Which source package did you use?  Vanilla?

 

I've cloned Linux-stable git and checked out the 3.16.y branch.

----------

## Chiitoo

I've simply edited the version numbers in the latest in-tree ebuild, and it seems to work fine enough here, from what I can tell!

I do hope that wherever aCOSwt has been/gone\taken to, that they're OK.  Nay... better than OK!  That, and that they may return once more again, or twice, or however many times is required.

Edit: Forgot to add... there might be plans on including these with the experimental USE-flag on gentoo-sources.

(TomWij) from comment #1)

> Might need this fixed when I bring ck to the experimental tarball of

> genpatches.

----------

## _Nomad_

 *Polyatomic wrote:*   

>  *_Nomad_ wrote:*   Any plans on releasing an updated ebuild for 3.16 ? 
> 
> Patch up manually  
> 
> 

 

Already am, just curious  :Razz: 

----------

## Cleus

Very cheat, but it works

Copy ck-sources-3.14.4.ebuild to ck-sources-3.16.5.ebuild 

Edit CK_VERSION="1" > CK_VERSION="2", BFS_VERSION="447" > BFS_VERSION="456"

ebuild ck-sources-3.16.5.ebuild digest

Manually download the patch files that are not downloaded from the previous command

emerge ck-sources

----------

## kernelOfTruth

BFS-460 for kernel 3.19:

http://ck-hack.blogspot.co.at/2014/12/bfs-460-linux-318-ck1.html?showComment=1423974000769#c7462595508848916476

currently running here without any noticable issues so far

ported BFS-460:

https://github.com/kernelOfTruth/linux/commits/linux-3.19-BFS-460_3.18-to-3.19

BFS-460 with patches from Alfred Chen:

https://github.com/kernelOfTruth/linux/commits/linux-3.19-BFS-460_3.18

----------

## yngwin

I have taken on maintainership of ck-sources, and pushed version 3.19.7 and 4.0.2 updates. 

Does anyone need updates to older versions, e.g. 3.14.x branch?

----------

## Myu

Hello everyone,

I'm currently experiencing mouse suttering and overall really poor responsiveness on gentoo-sources while my system is under some mid disk I/O (live imaging the drive with dattobd or copying the image to a NAS, iostat say 13% iowait)

Could ck-sources improve the responsiveness of my system ? I'm running Xfce + Compton, under normal load, everything is buttersmooth as far as I can tell.

I've read elsewhere that ck-sources do not play well with hibernate / suspend, is it still the case ? I kinda like hibernate  :Smile: 

Also I'm running the 4.2 series and ck-sources is on 4.1, should I wait for ck 4.2 for an easy migration ? 

Thanks in advance to those who answer.

Have a nice day !

----------

## spectromas

 *Myu wrote:*   

> 
> 
> I'm currently experiencing mouse suttering and overall really poor responsiveness on gentoo-sources while my system is under some mid disk I/O (live imaging the drive with dattobd or copying the image to a NAS, iostat say 13% iowait)
> 
> Could ck-sources improve the responsiveness of my system ? I'm running Xfce + Compton, under normal load, everything is buttersmooth as far as I can tell.
> ...

 

I get terrible performance issues while transferring large files over usb to NTFS and BFS or BFQ (or both together) don't make any difference for me. 

 *Myu wrote:*   

> 
> 
> I've read elsewhere that ck-sources do not play well with hibernate / suspend, is it still the case ? I kinda like hibernate 
> 
> 

 

Never had any problem with that, ck-sources is the same as gentoo-sources but with an extra patch or two.

----------

## Myu

Hello spectromas, thanks for your reply.

These performance issues are bizarre indeed. What filesize do you transfer usually ? On my end, the file is 38 GB large, I'm sending it though NFS via (g)rsync.

Kinda looks like the OS is allocating or using way too much resources while transferring the data...

I tried to stress another Gentoo I have with stress(1) and a hell lot of I/O workers, it never sutters the way it did on the machine where I have the issue.

I'll try to gather some more metrics. I'll be trying Linux-ck anyway, it looks good  :Smile: 

----------

## Chiitoo

As far as I understand (which isn't saying much), these patches (that implement the BFS) are more for the CPU-side of things, not so much for the I/O (for which you might experiment different IO Schedulers (I have Deadline, CFQ, and BFQ but I only really use BFQ so I can't really compare)).

With ck-sources and the BFS enabled, I can be compiling software with all my 6 CPU-cores in 100% use, and still play games and do whatever else I like while all that is going on.  Granted, I haven't tried without the BFS for a while, so I'm not sure how big of a difference it makes right now.

That said, the only time I ever have had slowdowns like mentioned here, stuttering mouse-cursor movement; a very unresponsive system, was when I was running out of RAM.  Now I have 16 GiBs of if, so I'll never fill all of it during normal use, even with some virtual machines running around.  ^^

I would recommend you to definitely give it a try, as you seem to have already decided to do.  You can keep your current/previous kernel(s) around just as well, like I did for a long time, though some time ago I cleaned them all up and stopped emerging gentoo-sources in addition to ck-sources.

Good luck, and welcome to ck!  ^^

----------

## Myu

 *Quote:*   

> As far as I understand (which isn't saying much), these patches (that implement the BFS) are more for the CPU-side of things, not so much for the I/O (for which you might experiment different IO Schedulers (I have Deadline, CFQ, and BFQ but I only really use BFQ so I can't really compare)). 

 

Indeed, I planned to use both, BFQ for I/O as well as BFS for CPU 

 *Quote:*   

> That said, the only time I ever have had slowdowns like mentioned here, stuttering mouse-cursor movement; a very unresponsive system, was when I was running out of RAM. Now I have 16 GiBs of if, so I'll never fill all of it during normal use, even with some virtual machines running around. ^^ 

 

I think you have a point ! I'm using a system with only 4 GB of RAM so it might be that when transferring a 38 GB file, I'm filling up whatever buffer too fast and then it starts swapping ! 

I'll try when I get back to my machine to see if it's indeed the root cause.

 *Quote:*   

> I would recommend you to definitely give it a try, as you seem to have already decided to do. You can keep your current/previous kernel(s) around just as well, like I did for a long time, though some time ago I cleaned them all up and stopped emerging gentoo-sources in addition to ck-sources. 

 

Yep, I'm gonna do just that ! 

 *Quote:*   

> Good luck, and welcome to ck! ^^

 

Thanks a lot !  :Smile: 

----------

## khayyam

 *Myu wrote:*   

>  *Quote:*   That said, the only time I ever have had slowdowns like mentioned here, stuttering mouse-cursor movement; a very unresponsive system, was when I was running out of RAM. Now I have 16 GiBs of if, so I'll never fill all of it during normal use, even with some virtual machines running around. 
> 
> I think you have a point ! I'm using a system with only 4 GB of RAM so it might be that when transferring a 38 GB file, I'm filling up whatever buffer too fast and then it starts swapping !

 

Myu ... it doesn't work like that, copying, or moving, a file will cause the file to be cached (see: page cache) but if the memory is needed subsequently that cache will be cleared ... you only access swap if there is no ram available. While additional ram will make the machine more responsive, the fact that its thrashing is mostly down to I/O ... and, perhaps, the filesystem used.

I suspect the reason behind your trashing is that you have an "Integrated Graphics Controller" sharing memory. I have a similar issue (Intel Corporation Mobile 945GM) and there is little that can be done about it other than via scheduling (BFS) and some trickery (ie, using ionice and schedtool).

Perhaps the following will offer a starter in that regard ...

/etc/portage/make.conf

```
MAKEOPTS="-j2" # you could also supply '-l 1.00' ... or what-have-you

PORTAGE_NICENESS="15"

PORTAGE_IONICE_COMMAND="ionice -c 3 schedtool -D \${PID}"

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} -j1 --load-average=1.00"
```

You can also adjust prority of command (ie, in the case of the file cp/mv above), eg:

```
% ionice -c3 nice -n 15 cp file /path/

% schedtool -D -e make -j2

% alias vnice='ionice -c3 nice -n 15'

% vnice mv file /path/

% ionice -c 2 nice -n -3 mpv file.mp4
```

Anyhow, I'd suggest enabling both BFS and BFQ and see how it goes ... you should also read the documentation for schedtool (sys-process/schedtool) and ionice (sys-apps/util-linux).

BTW, you can switch between IOSCHED via a kernel parameter ... eg: 'elevator=bfq' or 'elevator=cfq' ... if both are enabled in the kernel. 

HTH & best ... khay

----------

## spectromas

 *Myu wrote:*   

> 
> 
> These performance issues are bizarre indeed. What filesize do you transfer usually ? On my end, the file is 38 GB large, I'm sending it though NFS via (g)rsync.
> 
> 

 

Yes, it's very strange and frustrating, I just can't get to the bottom of it. I tried some live usb environment (Kubuntu) and got the same thing happening but then I tried in Porteus live environment didn't get the problem so I'm very confused about it and almost given up trying to solve it. I usually only transfer file up to around 6-7gb so not enormous. It doesn't seem to happen when transferring to ext4 or xfs so I assumed it's NTFS/FAT issue. The stuttering always appears for me after about 1.5gb has been transferred, before that it's smooth. 

 *Myu wrote:*   

> 
> 
> I tried to stress another Gentoo I have with stress(1) and a hell lot of I/O workers, it never sutters the way it did on the machine where I have the issue.

 

I've not managed to find any other way to reproduce it either. I did find a mention of it on the liquorix kernel forum which mentioned memory compaction. 

http://techpatterns.com/forums/about2443.html

I used their patches with those options disabled and things did improve a lot but the problem wasn't solved. So I am guessing it is either a kernel issue, something inherent in the way linux deals with particular filesystems, or some kind of hardware problem. 

But the other people are right, this SHOULD be down to the I/O schedulers rather than CPU schedulers. Having said that, there was a very nasty bug around linux 3.18 time with BFS which causes kernel panic with heavy disk I/O so at least sometimes it can be related. I've been very impressed with how much CFS and CFQ have improved, even just over the last year or so. BFS does make things seem a bit snappier but I don't get a huge improvement in performance and BFS has had some serious issues for the last couple of versions so I've stayed away from it. It seems to be more stable since the last release but for me it's simply not worth it.

----------

## mi_unixbird

So since Kolivas' patches for the 4.3.x line have been out for a short week now, any ETA on >ck-sources-4.1.6?

----------

## khayyam

 *mi_unixbird wrote:*   

> So since Kolivas' patches for the 4.3.x line have been out for a short week now, any ETA on >ck-sources-4.1.6?

 

mi_unixbird ... you can bump the package in a local overlay ... it should be sufficent to edit K_GENPATCHES_VER to reflect genpatches from gentoo-source-4.3.0 (so ... ="1") and CK_VERSION to reflect whatever the ck patch version currently is (so ... ="1") ... build the manifest, and emerge.

```
K_GENPATCHES_VER="1"

[...]

CK_VERSION="1"
```

If you're not familiar with local overlays then read the local overlay wiki page.

best ... khay

----------

## mi_unixbird

Yeah, just copying the default ck-sources ebuild and changing those things as well as changing a compression format from bz2 to xz  seems to work. The =ck-sources-4.1.6 also included the BFQ I/O Scheduler though, or at least mine does.

I had to patch that one in manually but with it it seems to work. Not sure if manually patching inside kernel sources is a good idea. The ebuild tekst seems to imply that BFQ scheduler is drawn in but no such thing happens, maybe I needed to change something else for that. It seems to work though.

----------

## mi_unixbird

So I switched back to 4.1.6 as my system crashed twice within 24 hours now, before this point it just didn't crash.

But I'm not sure if it's because of this or my switch from ext4 to btrfs on the same day, so I'll be running 4.1.6 with btrfs to see if it continues to crash.

----------

## khayyam

 *mi_unixbird wrote:*   

> So I switched back to 4.1.6 as my system crashed twice within 24 hours now, before this point it just didn't crash. But I'm not sure if it's because of this or my switch from ext4 to btrfs on the same day, so I'll be running 4.1.6 with btrfs to see if it continues to crash.

 

mi_unixbird ... if you look in your kmsg logs you should see the backtrace, and so the component causing the crash.

I've not moved to 4.x so I can't comment, but I generally hold off upgrading to a new major revision until its been better tested.

best ... khay

----------

## ulenrich

Hey, hey ... it is just too early to blindly assume bfs is the crasher. Linux-4.3.0 is the zero release without fixes and probably is full of bugs.

For me it works a few hours now.

----------

## thunderrd

I'd really like to see a new version get into the tree after seeing this in Con's IRC channel yesterday:

 *Quote:*   

> * conman (~con@220.240.178.83) has joined
> 
> <conman> woohoo improved throughput on next bfs
> 
> <entil> conman: you rock!
> ...

 

----------

## khayyam

 *thunderrd wrote:*   

> I'd really like to see a new version get into the tree after seeing this in Con's IRC channel yesterday:

 

thunderrd ... this is a diff against ck-sources-4.1.6.ebuild for ck-sources-4.3.2.ebuild (using 4.3-ck2) ... untested, but I did build the manifest and so *it should* find the required sources/patches, and merge.

```
17c17

< K_GENPATCHES_VER="10"

---

> K_GENPATCHES_VER="3"

19c19,20

< K_DEBLOB_AVAILABLE="1"

---

> K_DEBLOB_AVAILABLE="0"

> K_KDBUS_AVAILABLE="0"

39c40

< CK_FILE="patch-${K_BRANCH_ID}-ck${CK_VERSION}.bz2"

---

> CK_FILE="patch-${K_BRANCH_ID}-ck${CK_VERSION}.xz"
```

... so, not much you'd need to change ... and so you should be able to bump the package in a local overlay.

best ... khay

----------

## thunderrd

Thank you for that.

I will give it a try as soon as I have time, and report back.  It's a pity; it's been such a long time since this package has had a steady maintainer.  I feel bad asking for a version bump sometimes, I know that everyone is a volunteer.

----------

## spectromas

It does have a steady maintainer doesn't it? The patches themselves haven't been updated since August or something http://ck-hack.blogspot.com/

As far as I remember the ebuild gets updated fairly quickly.

----------

## thunderrd

The diff that khayyam provided works fine, builds and boots. There are quite a few new options in .config, though, so be ready.

As for the maintainer, I think yngwin is doing it now, but he's likely busy as there haven't been any updates in portage for two major versions [since 4.1.6, now at 4.3].  I'll see if I can talk to him in #gentoo if he's around.

----------

## khayyam

 *thunderrd wrote:*   

> The diff that khayyam provided works fine, builds and boots. There are quite a few new options in .config, though, so be ready.

 

thunderrd ... ok, good. I didn't intend to use it myself as I'll probably stick with 3.x for a while ... starting a config from scratch, which I tend to do for major kernel revisions, is not something I have time for right now.

best ... khay

----------

## spectromas

 *thunderrd wrote:*   

> there haven't been any updates in portage for two major versions [since 4.1.6, now at 4.3].

 

Yes, because there were not any ck patches released. Look at his blog, 4.1.6 was the last version until the recent new one. The guy from pf-sources was maintaining the patch and releasing it for his kernel sources but between 4.1.6 and now there was nothing to update to, it wasn't because the ebuild is unmaintained.

----------

## Chiitoo

The maintainer, yngwin, is in fact unavailable at this time, as can be seen here: Unavailable Gentoo Developers (devaway)

With that in mind, creating bug reports for version bumps for packages they maintain would probably be a good idea, so that another developer might perhaps jump to it.  ^^

----------

## mi_unixbird

So I've been running "4.3.2-ck" for a couple of days now without any issues. I think my initial issues were btrfs but you can never really tell. Latency certainly feels better but this might also be because I switched to on-demand cpufreq which I'm pretty sure is a bigger factor all in all.

I just took the 4.1.6-ck ebuild and put K_GENPATCHES_VER=3, changed the extension of the archive from bz to xz and that was it really.

I'm also back on ext4 as btrfs was giving me issues on the 4.1.6-ck kernel as well.

----------

## Chiitoo

One may want to set CK_VERSION="3" due to “detrimental effect on interactivity” in the earlier version.

Posted today at -ck hacking:

 *ck at ck-hack.blogspot.com wrote:*   

> Tuesday, 15 December 2015
> 
> BFS 467, linux-4.3-ck3
> 
> Announcing an updated BFS for linux-4.3 based kernels.
> ...

 

I just built mine (using 4.3.2 sources), but haven't tried booting yet.

----------

## mi_unixbird

No can't do m'lady. I already used my reboot quota for this year on the old update. The e-peen must remain strong. More than two reboots per year and you're basically a Windows and/or Ubuntu user.

----------

## ulenrich

I want to know about the new 0_or_1 setting of BFS 467, linux-4.3-ck3 

Is it possible to change at runtime the behavior of BFS by just 

echo "0" >/proc/sys/kernel/interactive

... which I would prefer having to compile quickly some ebuild

and then afterwards

echo "1" >/proc/sys/kernel/interactive

to get my snappy desktop again?

----------

## Zentoo

A little quick message to tell that I'm really happy with ck-sources kernel actually.

I'm using ck-sources since 4.04-r1.

I've posted this void message to keep track of this thread.

Thanks to everyone involved in this ebuild !

----------

## Chiitoo

 *ulenrich wrote:*   

> I want to know about the new 0_or_1 setting of BFS 467, linux-4.3-ck3 
> 
> Is it possible to change at runtime the behavior of BFS by just 
> 
> echo "0" >/proc/sys/kernel/interactive
> ...

 

That's pretty much how I understand it.  Setting 0 will make things happen like they do with BFS 466.

I tried flipping it around betwixt 1 and 0, while building Wine and running XCOM: Enemy Unknown.  While 0, switching between applications and stuff would become quite noticeably less snappy-like, and I had a few short freezes even.  When setting 1, things would seem to become fluid and snappy again.

Not a great test by any means, but it's something, I maybe guess.  ^^

----------

## ulenrich

I have done it: 

echo "0">/proc/sys/kernel/interactive

because I am transitioning to gcc-5.3 the whole night, by

emerge gcc; gcc-config set 2; emerge libtool

revdep-rebuild --library 'libstdc\+\+.so.6'

Arghh .... this is a long job compiling 196 C++ related ebuilds  :Sad: 

The linux43-bfs467 kernel is rock solid!

I suspect the new C++11 Abi needs more time for compilation than the older C++ language of 99.

Or the gcc-5.3 compiler needs optimization

Or the program source code could be optimized 

....

----------

## Zentoo

@ulenrich:

Compilation time with gcc-5.3 with new C++11 ABI don't take significantly more time than gcc-4 with C++99ABI:

```
     Fri Oct 30 02:22:04 2015 >>> media-video/vlc-2.2.1-r1

       merge time: 2 minutes and 32 seconds. (gcc4)

     Tue Dec 15 09:40:51 2015 >>> media-video/vlc-2.2.1-r1

       merge time: 2 minutes and 19 seconds. (gcc5)

     Tue Nov 10 03:55:41 2015 >>> app-office/libreoffice-5.0.3.2

       merge time: 1 hour, 4 minutes and 58 seconds. (gcc4)

     Tue Dec 15 16:57:46 2015 >>> app-office/libreoffice-5.0.3.2

       merge time: 1 hour, 7 minutes and 24 seconds. (gcc5)
```

But gcc5 compilation take more time than gcc4.

```

     Mon Dec 14 20:35:35 2015 >>> sys-devel/gcc-4.9.3

       merge time: 12 minutes and 45 seconds. 

     Mon Dec 14 16:25:00 2015 >>> sys-devel/gcc-5.3.0

       merge time: 20 minutes and 46 seconds.
```

In fact I've observed similar compilation time once I got recompiled my kernel with gcc 5 and reboot.

And my quick CPU scalability/memory throughput bench show that I got a +2.8 % gain with new gcc5.3 using kernel 4.1.6-ck.

Quick bench: 

```
cat /dev/zero | pv -ar | pbzip2 > /dev/null
```

=> 780 MiB/s with gcc4 kernel

=> 800 MiB/s with gcc5 kernel.

So I presume that gcc5 compilation is in reality a bit slower that gcc4 but it's balanced by a better throughput with a gcc5 compiled kernel.

----------

## mi_unixbird

4.3.2-ck has crashed a couple of times already on me the last few days, not sure if this is due to the 4.3.2 kernel or the ck version, I'm going to try with ck3 (I had 1) and if that crashes again I'll be back at 4.1.6 I guess.

----------

## Chiitoo

I believe I'm on my third day with 4.3.2 and BFS 467, without a single crash or any other issues (aside from what the quick test I mentioned earlier brought up; I have not played more with the /proc/sys/kernel/interactive  setting though, having left it at 1).

----------

## mi_unixbird

Wel, 4.3.2-ck3 has not crashed on me yet since that last message. So it looks okay.

The crashes are rarely arbitrary though. Like, one of them happened when I was testing some OCaml code and accidentally made a fifo with it with decimal permissions 600 instead of  octal and the entire box blew.

----------

## thunderrd

Agreed, the -ck3 patches are doing a good job for me as well.

Version bump request has been filed today, let's see if someone picks it up:

https://bugs.gentoo.org/show_bug.cgi?id=569262

----------

## Ant P.

2¢:

I've been using zen-sources.git's version of the -ck stuff for a long time now, and I've had maybe one or two inexplicable kernel crashes in that time (setting CONFIG_PANIC_TIMEOUT turned out a good idea) and a few failures to compile at all around 4.2. But to be honest the only real instability I've seen all year was the one time I turned blk-mq on. That was... bad.

----------

## mi_unixbird

Well, I found _one_ cause of a crash. Whenever I go to https://www.youtube.com/user/TotalHalibut it crashes on me, I've reproduced this three times in a row now.

Other youtube pages do not crash on me like that.

Edit, and after clearing my youtube cookies it no longer crashes. That's quite interesting.

----------

## mi_unixbird

Right, I think I have fully fixed it now, it was pretty stupid. I always ignore and delete all the etc-update shit without much thinking because they tend to overwrite my configs. This time however I should've paid more attention, the chrome-binary-plugins etc-update of course needed to set the flags to appropriately use the path of the new flash browser.

Still though, I'm not comfortable with this. This seems to imply that a user without root access can crash the system by manipulating that variable. That should surely not be able to happen right? Or does the flash plugin actually include something setuid or a kernel module. If not, then it's a kernel flaw in my opinion. A non root normal user process behaving improperly should never be able to bring the entire system to a halt.

----------

## thunderrd

No problems here using Firefox and flash plugin OR Firefox and html5.  I would guess that is a browser-related issue.

You can't run etc-update without root, how can a non-root user *manipulate the variable*?

----------

## mi_unixbird

 *thunderrd wrote:*   

> You can't run etc-update without root, how can a non-root user *manipulate the variable*?

 This specific configuration file just sets extra command line arguments in an environment variable when chromium is started. Specifically, this is in the file:

```
CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --ppapi-flash-path=/usr/lib64/chromium-browser/PepperFlash/libpepflashplayer.so --ppapi-flash-version=20.0.0.248"
```

The --papi-flash-version being wrong was what seemed to have caused the crashes, it has not crashed on me since by watching youtube pages. But the issue is, you can just run chromium as non root and pass that flag manually in the wrong way. Unless I understand something wongly about linking the .so, it seems to me you can just put that file into your home directly if you want, link to it that way and pass the wrong version to crash an entire system by going to a youtube page. That should surely not be possible of a multi-user system?

----------

## Myu

Hello ck-users ! 

I've some trouble understanding why noop is still registred as my default i/o scheduler on my SSD but not on my HDD ... could someone give me an idea where to look ? 

It looks like Linux automatically choose to put noop on the SSD and BFQ everywhere else, maybe it makes sense but I would like to know why out of curiosity...

dmesg looks happy : 

```
[    0.293432] io scheduler noop registered

[    0.293579] io scheduler bfq registered (default)

[    0.293723] BFQ I/O-scheduler: v7r8

[    0.748630] BFS CPU scheduler v0.464 by Con Kolivas.

```

```
myu@Dwarf /home/myu/Desktop ~$ cat /sys/block/sda/queue/scheduler

[noop] bfq 

myu@Dwarf /home/myu/Desktop ~$ cat /sys/block/sdb/queue/scheduler

noop [bfq] 

myu@Dwarf /home/myu/Desktop ~$ cat /sys/block/sdc/queue/scheduler

noop [bfq] 

```

I'm using Linux 4.1.6-ck

Cheers and a happy new year =)

----------

## Myu

Hi ck-users,

Is there any plan for a 4.3-based ck release ? 

Linux 4.3.3-3 fix the rather serious CVE-2016-0728.

On a side note, is making the ck-ebuild version bumps difficult ? I've a rather small experience with ebuild(s) but some good will and free time to invest so maybe I can help.

EDIT : If your kernel .config does not include CONFIG_KEYS then there's no need for a patch.

----------

## khayyam

 *Myu wrote:*   

> Linux 4.3.3-3 fix the rather serious CVE-2016-0728.

 

Myu ... are you sure, 4.3.3 is from 2015-12-15, and generally you'd have a version bump for a CVE.   

 *Myu wrote:*   

> On a side note, is making the ck-ebuild version bumps difficult ? I've a rather small experience with ebuild(s) but some good will and free time to invest so maybe I can help.

 

No, not terribly. All you need to is check that K_GENPATCHES_VER matches that of the same gentoo-sources release, and that CK_VERSION matches whatever is available from C. Kolivas. So,

```
K_GENPATCHES_VER="4"

[...]

CK_VERSION="3"
```

best ... khay

----------

## Myu

 *Quote:*   

> Myu ... are you sure, 4.3.3 is from 2015-12-15, and generally you'd have a version bump for a CVE. 

 

Yeah I've not be clear enough, this is from Arch Linux, it correspond to gentoo-sources-4.3.3-r1

 *Quote:*   

> No, not terribly. All you need to is check that K_GENPATCHES_VER matches that of the same gentoo-sources release, and that CK_VERSION matches whatever is available from C. Kolivas. So

 

That's interesting. I will take a look when I get the chance, hopefully soon ! 

Thanks Khay.

----------

## Myu

Sorry for any spam if you're subscribed to this topic but I thought I would share my ck-sources ebuild for ck-sources-4.3.3-r1 if anyone wants it; here it is : 

https://bpaste.net/show/70f29b143570 ( expires in 1 month )

Works fine : Linux Dwarf 4.3.3-ck-r1-gnu #1 SMP Thu Jan 21 18:27:31 CET 2016 x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux

----------

## khayyam

 *Myu wrote:*   

> Sorry for any spam if you're subscribed to this topic but I thought I would share my ck-sources ebuild for ck-sources-4.3.3-r1 if anyone wants it; here it is:

 

Myu ... note that bpaste will serve up the file (raw) as DOS (CRLF line terminators) so it will need to be converted (ie, via app-text/dos2unix) before building the digest (portage expects plain ascii).

```
% wget --quiet -O - https://bpaste.net/raw/70f29b143570 | file -

/dev/stdin: ASCII text, with CRLF line terminators
```

If you wanted to continue bumping you could create bug reports and attatch ebuilds, or create a github (or similar) account to host an overlay.

best ... khay

----------

## Myu

Hi khay,

 *Quote:*   

> Myu ... note that bpaste will serve up the file (raw) as DOS (CRLF line terminators) so it will need to be converted (ie, via app-text/dos2unix) before building the digest (portage expects plain ascii). 

 

Odd, I didn't know that, TIL thanks !

I don't mind continuing bumping this ebuild, if it helps, I would gladly keep track of it and keep it as up-to-date as possible, and why not through proxy-maintaining ? We'll see I guess.

----------

## khayyam

Myu, et al ...

here is a diff against your 4.3.3-r1 for ck-sources-4.3.4

```
17c17

< K_GENPATCHES_VER="5"

---

> K_GENPATCHES_VER="6"
```

... didn't build but the patches apply as expected.

best ... khay

----------

## thunderrd

FWIW, the hnaparst overlay [ https://github.com/hnaparst/overlay] is keeping up with ck updates regularly - good work by Harold Naparst.

Add the overlay with layman and emerge from there.  I've used the last 3 versions with no problems at all, now on 4.5.4.

----------

## thunderrd

The above overlay I referred to now has an updated ck-sources-4.7.0.  I have tested it and it builds correctly and boots, although some patching is needed [on the drivers, not the kernel] if you use the proprietary nvidia-drivers.

----------

## Ant P.

Maybe it's time I jump ship from zen-kernel to this; I got bitten by the CONFIG_SMT_NICE thing which that ebuild already patched. Would've saved me hours of hopeless confusion...

Having said that, I'm currently running 4.7.0 on CFS + cpufreq_schedutil with no problems. The new thing handles medium-high load way better than ondemand ever did. Should be even better without CFS :)

----------

## Ant P.

Okay, after a bit more experimentation it looks like the combination of BFS+schedutil is what causes a crash. So... don't use that in 4.7.0.

----------

## thunderrd

The hnaparst overlay I have referred to before is keeping up-to-date on recent developments with Con's work - namely the new scheduler, intended to eventually replace BFS, named MuQSS:

https://forums.gentoo.org/viewtopic-p-7972188.html?sid=5cb1077b6878a13ff4ef8bb0375e541a

https://ck-hack.blogspot.com.au/

----------

## Massimo B.

Is ck-sources the only kernel right now offering the BFQ IO scheduler? I'm with ck-sources for a long time and need to test an issue on gentoo-sources-4.11.0. Emerged with USE="experimental" but the BFQ is not there.

----------

## Juippisi

PF-sources does have BFQ, but its not updated to 4.11 in main portage yet. You can probably find it from an overlay, or download and patch manually from 

https://pf.natalenko.name/

----

https://dev.gentoo.org/~mpagano/genpatches/trunk/4.11/

You can also manually patch BFQ with patches found from here, they will be added to gentoo-sources-4.11.1 if you want to wait for that.

----------

## Massimo B.

Trying to figure out the benefits of pf-sources over ck-sources... -cf and BFQ patches are already part of ck-sources. But then there is   4. [m] graysky's kernel GCC patch.  According README that should offer    Native optimizations autodetected by GCC  -march=native.

But that I already have that option in ck-sources and gentoo-sources.

----------

## Juippisi

Yes, nowadays there really isnt a reason to use pf-sources over ck-sources. Pf-sources used to have UKSM patch, tuxonice patches, aufs patch... maybe more. If you want something thats hot right now, you could try https://liquorix.net/ liquorix-sources. IVe seen it in some overlay as well, but manually patching isnt hard either.

----------

## Ant P.

BFQ is in vanilla 4.12, so you won't need that patch soon.

----------

## Massimo B.

 *Juippisi wrote:*   

> Yes, nowadays there really isnt a reason to use pf-sources over ck-sources. Pf-sources used to have UKSM patch, tuxonice patches, aufs patch... maybe more. If you want something thats hot right now, you could try https://liquorix.net/ liquorix-sources. IVe seen it in some overlay as well, but manually patching isnt hard either.

 Any reason to prefer sys-kernel/liquorix-sources from stuff overlay to ck-sources? Curiously the installed sources are named like old pf-sources: linux-4.10.16-pf1/

liquorix brings some more settings and patches beside MuQSS and BFQ which are already in  ck-sources.

When it comes to IO and IO schedulers I had issues with slow block devices, so here I'm going for more ram caching now:

```
# sysctl -a | grep dirty.*ratio

vm.dirty_background_ratio = 20

vm.dirty_ratio = 50
```

But what should really make a difference here now is this patch since 4.10+(https://lwn.net/Articles/682582/), which should be available in all the kernels, though I'm on 4.10.14-ck currently:

```
# zgrep BLK_WBT /proc/config.gz 

CONFIG_BLK_WBT=y

CONFIG_BLK_WBT_SQ=y

CONFIG_BLK_WBT_MQ=y
```

----------

## Massimo B.

I took a look at pf-sources for that UKSM and that sounds really interesting even on Desktop systems. Not sure if it is worth the Cpu load if I have plenty of RAM space anyway. Not sure how much duplication there is on usual desktops with browser and stuff.

One thing I wondered about, I'm running liquorix-sources now, thinking it is all the -cf sources plus more. But now I see liquorix has only cherry-picked the MuQSS and dropped all the rest of ck patches likes this:

http://ck.kolivas.org/patches/4.0/4.11/4.11-ck2/patches/

Is that right?

So finally I'm staggering again about wether to take liquorix, -pf or -ck.

----------

