Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ck-sources : All about choice !
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5 ... 9, 10, 11  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Mar 13, 2013 11:49 am    Post subject: Reply with quote

@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.
_________________
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Wed Mar 13, 2013 3:16 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Mar 13, 2013 3:51 pm    Post subject: Reply with quote

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...
_________________
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Wed Mar 13, 2013 5:05 pm    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Mar 13, 2013 6:16 pm    Post subject: Reply with quote

You are welcome Ant P.
_________________
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Mar 18, 2013 10:21 pm    Post subject: Reply with quote

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

_________________
Back to top
View user's profile Send private message
jasn
Guru
Guru


Joined: 05 May 2005
Posts: 439
Location: Maryland, US

PostPosted: Tue Mar 19, 2013 9:46 pm    Post subject: Reply with quote

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..
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Tue Mar 19, 2013 11:32 pm    Post subject: Reply with quote

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. :lol:
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Wed Mar 20, 2013 12:42 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Mar 20, 2013 10:17 am    Post subject: Reply with quote

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 8O
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 ! 8)

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

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 ! :roll:
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:

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


Last edited by aCOSwt on Fri Mar 22, 2013 1:23 pm; edited 3 times in total
Back to top
View user's profile Send private message
jasn
Guru
Guru


Joined: 05 May 2005
Posts: 439
Location: Maryland, US

PostPosted: Wed Mar 20, 2013 12:30 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Mar 20, 2013 2:53 pm    Post subject: Reply with quote

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 :
Code:
# 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:
_________________
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Mar 21, 2013 8:02 am    Post subject: Reply with quote

ulenrich wrote:
@all, who can reproduce these time accounting overflows?

ACK :!: 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... :D

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 :!: 8O 8O
This field being in turn the decimal representation of 0xFFFFFFFFFFFFFFFF... Normal !

EDIT2 :
Con wrote:
good work, now go in and fix it

:evil: ulenrich ! I... hmmm... I... hate you ! :evil:
_________________


Last edited by aCOSwt on Fri Mar 22, 2013 10:38 am; edited 3 times in total
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Thu Mar 21, 2013 3:51 pm    Post subject: Reply with quote

@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?
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Mar 21, 2013 8:29 pm    Post subject: Reply with quote

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.
_________________
Back to top
View user's profile Send private message
xming
Guru
Guru


Joined: 02 Jul 2002
Posts: 441

PostPosted: Fri Mar 22, 2013 12:36 pm    Post subject: Reply with quote

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.
_________________
http://wojia.be
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Fri Mar 22, 2013 12:52 pm    Post subject: Reply with quote

aCOSwt wrote:
recommends 7 for gamers

Do I? :lol:

Actually, what I find best these days is:
Code:
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 :?


Last edited by PaulBredbury on Fri Mar 22, 2013 1:42 pm; edited 4 times in total
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Fri Mar 22, 2013 1:04 pm    Post subject: Reply with quote

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

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 ! :P

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


Last edited by aCOSwt on Fri Mar 22, 2013 9:03 pm; edited 11 times in total
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Fri Mar 22, 2013 1:29 pm    Post subject: Reply with quote

PaulBredbury wrote:
aCOSwt wrote:
recommends 7 for gamers

Do I? :lol:

OK... I changed for "used to recommend" :P
PaulBredbury wrote:
Actually, what I find best these days is:
Code:
echo 4 > /proc/sys/kernel/rr_interval

Maybe I'm getting fussier.

No no... you just... like to contradict me. :D
I don't really mind, each time you do, I learn something ! :twisted:
_________________
Back to top
View user's profile Send private message
xming
Guru
Guru


Joined: 02 Jul 2002
Posts: 441

PostPosted: Sat Mar 23, 2013 9:08 am    Post subject: Reply with quote

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.
_________________
http://wojia.be
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Sat Mar 23, 2013 6:46 pm    Post subject: Reply with quote

xming wrote:
apci_pm got really much better, so this is my clocksource now.

Yeah, I've switched back to:
Code:
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:
Code:
hpet_acpi_add: no address or irqs in _CRS


And processor.max_cstate=1 (2 is not sufficient) improves the TSC from:
Code:
Marking TSC unstable due to TSC halts in idle

to:
Code:
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:
Code:
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
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Mon Mar 25, 2013 1:39 am    Post subject: Reply with quote

Okay, looks like I have a problem...

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

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)...
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 59

PostPosted: Mon Mar 25, 2013 5:38 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Mar 25, 2013 10:50 am    Post subject: Reply with quote

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.
_________________
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Mar 25, 2013 1:26 pm    Post subject: Reply with quote

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.
_________________
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5 ... 9, 10, 11  Next
Page 4 of 11

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum