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.

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 definitelyupgrade to 3.4.34 / 3.6.11-r2 or 3.7.10-r1

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:

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

Last edited by aCOSwt on Mon Mar 25, 2013 8:31 pm; edited 6 times in total

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

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:

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

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

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

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

Hmmm... again interesting those running 4096 cpus systems ? For sure !
As far as I am personally concerned... Hmmm

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

Last edited by aCOSwt on Mon May 06, 2013 5:17 pm; edited 4 times in total

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 _________________fun2gen2

Last edited by ulenrich on Mon May 06, 2013 3:14 pm; edited 1 time in total

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

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

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.

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

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 !_________________fun2gen2

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?