/ home / blog
brain activity log

21.07.2007 - Saturday - 10:00 - Ace Of Space

On thursday night we had a 30 minute show at the BARt contest in Casole D'Elsa.

Ok.. we didn't win after all but we got the critics prize and had a looooot of fun :)

I'll post some photos soon.



11.07.2007 - Wednesday - 17:20 - Deterministic God

I have always been an Ingo's fan. A couple of days ago his Completely Fair Scheduler has been merged into the kernie :)

"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100% physical power and which can run each task at precise equal speed, in parallel, each at 1/nr_running speed. For example: if there are 2 tasks running then it runs each at 50% physical power - totally in parallel.

On real hardware, we can run only a single task at once, so while that one task runs, the other tasks that are waiting for the CPU are at a disadvantage - the current task gets an unfair amount of CPU time. In CFS this fairness imbalance is expressed and tracked via the per-task p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of time the task should now run on the CPU for it to become completely fair and balanced.

(small detail: on 'ideal' hardware, the p->wait_runtime value would always be zero - no task would ever get 'out of balance' from the 'ideal' share of CPU time.)

CFS's task picking logic is based on this p->wait_runtime value and it is thus very simple: it always tries to run the task with the largest p->wait_runtime value. In other words, CFS tries to run the task with the 'gravest need' for more CPU time. So CFS always tries to split up CPU time between runnable tasks as close to 'ideal multitasking hardware' as possible.

In practice it works like this: the system runs a task a bit, and when the task schedules (or a scheduler tick happens) the task's CPU usage is 'accounted for': the (small) time it just spent using the physical CPU is deducted from p->wait_runtime. [minus the 'fair share' it would have gotten anyway]. Once p->wait_runtime gets low enough so that another task becomes the 'leftmost task' of the time-ordered rbtree it maintains (plus a small amount of 'granularity' distance relative to the leftmost task so that we do not over-schedule tasks and trash the cache) then the new leftmost task is picked and the current task is preempted.

The rq->fair_clock value tracks the 'CPU time a runnable task would have fairly gotten, had it been runnable during that time'. So by using rq->fair_clock values we can accurately timestamp and measure the 'expected CPU time' a task should have gotten. All runnable tasks are sorted in the rbtree by the "rq->fair_clock - p->wait_runtime" key, and CFS picks the 'leftmost' task and sticks to it. As the system progresses forwards, newly woken tasks are put into the tree more and more to the right - slowly but surely giving a chance for every task to become the 'leftmost task' and thus get on the CPU within a deterministic amount of time.

CFS's design is quite radical: it does not use runqueues, it uses a time-ordered rbtree to build a 'timeline' of future task execution, and thus has no 'array switch' artifacts (by which both the vanilla scheduler and RSDL/SD are affected).

CFS uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail. Thus the CFS scheduler has no notion of 'timeslices' and has no heuristics whatsoever. There is only one central tunable /proc/sys/kernel/sched_granularity_ns which can be used to tune the scheduler from 'desktop' (low latencies) to 'server' (good batching) workloads. It defaults to a setting suitable for desktop workloads.

Due to its design, the CFS scheduler is not prone to any of the 'attacks' that exist today against the heuristics of the stock scheduler: fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c all work fine and do not impact interactivity and produce the expected behavior.



10.06.2007 - Sunday - 02:57 - Wrong place ?

It is very interesting to note that a lot of people I admire, love, consider a friend or have admired, loved, considered a friend in the past are disappearing from this place. They're simply going somewhere else to work, have fun, live.

Most of them don't even spend time in criticizing this place anymore: they simply leave.

Ugly ... and maybe a little bit scary too :/

[20/07/2007 09:17:07]   <Valentina> 
 
eh, lo fanno, lo fanno! qualcuno che conosco?
[20/07/2007 12:57:14]   <Pragma> 
 
Hm. Vabbeh, per quanto riguarda te, venendo da fuori era pure prevedibile che andassi a vivere altrove... D'altra parte pure tu confermi la regola: se fosse stato un posto fico, magari saresti rimasta qui. Per gli altri non so se conosci. E' possibile pero' :)



02.06.2007 - Saturday - 03:33 - I know the pieces fit
 

I know the pieces fit
cuz I watched them fall away.
Mildewed and smoldering,
fundamental differing.
Pure intention juxtaposed
will set two lovers souls in motion.
Disintegrating as it goes
testing our communication.
The light that fueled our fire
then has burned a hole between us so
we cannot see to reach an end
crippling our communication.

I know the pieces fit
cuz I watched them tumble down.
No fault, none to blame
it doesnt mean I dont desire
to point the finger, blame the other,
watch the temple topple over.
To bring the pieces back together,
rediscover communication.

The poetry that comes from
the squaring off between,
and the circling is worth it.
Finding beauty in the dissonance.

There was a time that the pieces fit,
but I watched them fall away.
Mildewed and smoldering,
strangled by our coveting
I've done the the math enough
to know the dangers of a second guessing.
Doomed to crumble unless we grow,
and strengthen our communication.

Cold silence has
a tendency to
atrophy any
sense of compassion.

F F C C G G A

Between supposed lovers.
Between supposed lovers.

And I know the pieces fit.
And I know the pieces fit.
And I know the pieces fit.
And I know the pieces fit.

I've transcribed the intro and a part of the first verse. It's enough to explain most of the tricks used in the song. The GP5 file is here. It contains the parts for two guitars, bass, drums and a guitar-arranged voice melody. It sounds really better with the RSE engine. Drop me a mail if you want the pdf.




30.05.2007 - Tuesday - 20:07 - A random video from NY

This is a random sax solo, from a random concert of a random band in a totally random club somewhere in NY in a random weekday...

Click the image to download the video...

Ah.. and I've finally posted some random photos here :)

I'm off to the gym. Later ppl.



want more ?

... really ? :D

Browse around then.

You're viewing 5 posts per page: you can view more or less, if you want.

The entries marked in red are the ones you're viewing now.

2007.09.18-06.07
2007.09.09-04.27
2007.08.26-02.23
2007.08.21-02.02
2007.08.12-20.15
2007.07.22-11.30
2007.07.21-10.00
2007.07.11-17.20
2007.06.10-02.57
2007.06.02-03.33
2007.05.30-20.07
2007.05.21-11.35
2007.04.14-21.53
2007.03.26-02.22
2007.03.23-10.12
2007.03.20-18.10
2007.03.16-01.10
2007.03.12-21.43
2007.03.12-03.57
2007.03.05-13.08
2007.02.25-22.21
2007.02.14-23.30
2007.01.02-02.55
2006.12.17-17.01
2006.11.26-20.26
2006.11.22-03.14
2006.11.21-01.30
2006.11.04-05.09
2006.09.16-04.18
2006.08.18-03.45
2006.08.14-17.58
2006.08.14-03.08
2006.08.02-20.38
2006.07.25-04.10
2006.07.25-03.14
2006.06.23-18.12
2006.06.02-13.25
2006.05.18-16.27
2006.05.18-14.30
2006.05.17-19.30
2006.04.29-19.30
2006.04.26-01.48
2006.04.22-13.06
2006.04.16-12.26
2006.04.11-03.10
2006.04.10-04.32
2006.04.08-14.59
2006.04.07-14.54
2006.04.06-09.00
2006.04.05-23.10
2006.04.05-11.00
2006.04.04
2006.04.03
2006.04.02
2006.04.01
2006.03.31
2006.03.27
2006.03.26
2006.03.25
2006.03.24
2006.03.23
2006.03.22
2006.03.20
2006.03.19
2006.03.17
2006.03.14
2006.03.07
2006.03.05
2006.02.23
2006.02.19
2006.02.13
2006.01.10
2005.12.29
2005.09.24
2005.09.21
2005.08.21
2005.08.18
2005.07.31
2005.07.04
2005.06.13
2005.04.10
2005.04.05
2004.12.18
2004.12.17
2004.12.16
2004.12.15
2004.12.14
2004.12.13
2004.12.12
2004.12.11
2004.12.10
2004.12.09
2001.06.02