A number of minor issues have been reported with BFS over time (interestingly none of them appear to be new). Some of them were cosmetic, like the reported suspicious rcu warning on startup, and the accounting for close to 100% bound cpu tasks flicking between 99 and 101%.

The most interesting actual bug was that clock_nanosleep, and timer_create would not work when used with the clock id of CLOCK_PROCESS_CPUTIME_ID. This is a timer which goes off based on the total CPU used by a process or its thread group, which I have never used myself nor was aware of its intricacies. This bug was only picked up as part of building and glibc testing by Olivier Langlois. This was an interesting bug for a number of reasons to me. First was that it had never manifested as far as I'm aware anywhere in the wild despite being a posix 2001 function, so presumably it is almost never used. Second is it's one of the few functions that tries to get accounting as a total of all the CPU used by a thread group rather than just per thread. Third is that you cannot really use clock_nanosleep with this clock id unless it is done from a separate thread to the one consuming CPU (since it puts the calling thread to sleep) so there would be precious few scenarios it would be in use currently, though coding multithreaded apps that use it for resource monitoring and control would make complete sense. Finally the most interesting part was I can now tell that it had been in BFS since its first release and no one had ever noticed as far as I'm aware.

Unfortunately it took me quite a while to find since I had to dig deep into figuring out how the whole system of timers works on a low level in the kernel before finally stumbling across one tiny piece of accounting/reporting that was missing on BFS. It's funny that a bug that directly affected almost no one should be so hard to track down. In the meantime it allowed me to tweak a number of bits of internal accounting so hopefully that should have improved as well.

Uups, got a time accounting overflow again: began at a kworker thread and then consecutive new threads.

Is there a correctly working initializing of times spent of new jobs in place already? Perhaps it initializes with a random memory value, which would tell me why this occures after some hours?Ralph Ulrich

By the way if I can't reproduce it, it's very difficult to debug a problem, and time is always an issue. However since I have had time recently, if you could email me with more details we might be able to debug it together if you're willing to try various patches.

I am just doing fine without time account overflows by tuning further RCU:

zcat /proc/config.gz |grep RCU# RCU SubsystemCONFIG_TREE_PREEMPT_RCU=yCONFIG_PREEMPT_RCU=y# CONFIG_RCU_USER_QS is not setCONFIG_RCU_FANOUT=32CONFIG_RCU_FANOUT_LEAF=4# CONFIG_RCU_FANOUT_EXACT is not set# CONFIG_TREE_RCU_TRACE is not setCONFIG_RCU_BOOST=yCONFIG_RCU_BOOST_PRIO=14CONFIG_RCU_BOOST_DELAY=320CONFIG_HAVE_RCU_USER_QS=y# CONFIG_PROVE_RCU_DELAY is not set# CONFIG_SPARSE_RCU_POINTER is not setCONFIG_RCU_CPU_STALL_TIMEOUT=32CONFIG_RCU_CPU_STALL_VERBOSE=yCONFIG_RCU_CPU_STALL_INFO=y# CONFIG_RCU_TRACE is not set

Con, if you want to reproduce you could try RCU config variations in the opposite direction. Beside I also use io deadline queue and not set NO_HZ.Ralph Ulrich

I tried many .config variations, but get a time accounting overflow anyway after some runtime. No luck so far.

As of curiousity I tried to Bfs patch the new Linux-3.8rc:- many line moves- 5 fuzzy patches going through- 2 rejects at ondemand.c

I can observe this overflow happening when compiling staff for my Gentoo installation. Activity in the ondemand module might be involved while the time accounting failure occures.Maybe the next Linux version is error free :)

Hi, CK. For the accounting problem, I am not sure if this one is the one you trying to solve. But I still find this with 427 with 3.7.7 kernel. To reproduce it:1. compile the kernel source, (I used 'time make -j4')2. use top to monitoring, some as processes will show with 9999 %CPU and a huge TIME+

ck are you working on a 3.8 patch ?I failed to merge the 3.7 patch into the new kernel. There seem to be some bigger changes in the scheduler interface. Probably related to the new rcu stuff... I'm eager to test this with bfs but no way to "brute force" the old code into the new kernel :)

Regarding the RCU stuff... I've experimented with it on my unicore uniprocessor. At first there are less kernel config options for me -- o.k. But changing the remaining rest of them did not make any difference in usability. Before always using kernel standard 500:0, I did 257:10, 331:10, last one, 101:99:

~ # zcat /proc/config.gz |grep RCU# RCU SubsystemCONFIG_TINY_PREEMPT_RCU=yCONFIG_PREEMPT_RCU=y# CONFIG_TREE_RCU_TRACE is not setCONFIG_RCU_BOOST=yCONFIG_RCU_BOOST_PRIO=99CONFIG_RCU_BOOST_DELAY=101# CONFIG_PROVE_RCU_DELAY is not set# CONFIG_SPARSE_RCU_POINTER is not set# CONFIG_RCU_TRACE is not set

Only taking prime numbers in delay/frequency as it prevents reoccurrence. ;-)

Varying these values seems to be useless to systems with one CPU/Core. But disabling RCU Boost resulted in hiccups in video and audio.

World's Most Popular Cars, Hot Speed Cars, Hot Cars with Hot Girls, Cars Latest Pictures with all info, Latest updates Cars Models and Company Cars, Strange Vehicles, Concept Cars, Top 10 Expensive Cars in the World.Visit this Link for More Strange Vehicles and Cars with Latest info and PicturesWorldLatestVehicles.com