ck-sources : All about choice !

Message

Post by **aCOSwt** » Wed May 08, 2013 9:51 am

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

Post by **aCOSwt** » Wed May 15, 2013 9:42 pm

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. · Post by **Ant P.** » Mon May 27, 2013 3:16 am

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!

Post by **aCOSwt** » Tue May 28, 2013 10:45 am

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

more or less

ignore

THE boolean quality / property / characteristic the entire design is based on.
(OK... offering the possibility... without totally ruining the entire system I mean...

)

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 !

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

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 · Post by **kernelOfTruth** » Tue May 28, 2013 3:07 pm

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 · Post by **ulenrich** » Tue May 28, 2013 6:13 pm

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

Time for kernel.org for another new LTS !

Post by **aCOSwt** » Tue May 28, 2013 7:29 pm

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%

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 :

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 · Post by **ulenrich** » Tue May 28, 2013 10:17 pm

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

Post by **aCOSwt** » Thu Jun 06, 2013 9:47 am

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 ?

Post by **aCOSwt** » Tue Jun 25, 2013 10:54 am

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

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. · Post by **Ant P.** » Tue Jun 25, 2013 3:12 pm

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

Ant P. · Post by **Ant P.** » Fri Jul 12, 2013 9:33 pm

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

Post by **aCOSwt** » Sat Jul 13, 2013 8:36 am

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

AFAIK, David Airlie is living in Brisbane...

thunderrd · Post by **thunderrd** » Sun Jul 21, 2013 4:31 pm

Regarding 3.9.7, I have something strange happening.

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

Code: Select all

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

Code: Select all

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

Post by **aCOSwt** » Sun Jul 21, 2013 4:57 pm

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 · Post by **thunderrd** » Mon Jul 22, 2013 3:50 am

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.

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 · Post by **thunderrd** » Tue Jul 23, 2013 3:23 pm

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.

Post by **aCOSwt** » Tue Jul 23, 2013 3:46 pm

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 · Post by **thunderrd** » Tue Jul 23, 2013 4:04 pm

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?

Post by **aCOSwt** » Tue Jul 23, 2013 4:37 pm

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

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

Post by **aCOSwt** » Tue Jul 23, 2013 4:51 pm

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 · Post by **ulenrich** » Tue Jul 23, 2013 9:25 pm

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

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.

Post by **aCOSwt** » Tue Jul 23, 2013 11:23 pm

ulenrich wrote:Isn't it better to wait for 3.10.6 or something? Let me explain...

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 · Post by **TomWij** » Tue Jul 23, 2013 11:39 pm

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

Post by **aCOSwt** » Wed Jul 24, 2013 9:24 am

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