Hi, On Fri, 10 Aug 2007, Ingo Molnar wrote:
> > I disabled the jiffies logic and the result is still the same, so this > > problem isn't related to resolution at all. > > how did you disable the jiffies logic? I commented it out. > Also, could you please send me > the cfs-debug-info.sh: > > http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh > > captured _while_ the above workload is running. This is the third time > i've asked for that :-) Is there any reason to believe my analysis is wrong? So far you haven't answered a single question about the CFS design... Anyway, I give you something better - the raw trace data for 2ms: 1186747669.274790012: update_curr 0xc7fb06f0,479587,319708,21288884188,159880,7360532 1186747669.274790375: dequeue_entity 0xc7fb06f0,21280402988,159880 1186747669.274792580: sched 2848,2846,0xc7432cb0,-7520413 1186747669.274820987: update_curr 0xc7432ce0,29302,-130577,21288913490,1,-7680293 1186747669.274821269: dequeue_entity 0xc7432ce0,21296077409,1 1186747669.274821930: enqueue_entity 0xc7432ce0,21296593783,1 1186747669.274826979: update_curr 0xc7432ce0,5707,5707,21288919197,1,-7680294 1186747669.274827724: enqueue_entity 0xc7432180,21280919197,639451 1186747669.274829948: update_curr 0xc7432ce0,1553,-318172,21288920750,319726,-8000000 1186747669.274831878: sched 2846,2847,0xc7432150,8000000 1186747669.275789883: update_curr 0xc7432180,479797,319935,21289400547,159864,7360339 1186747669.275790295: dequeue_entity 0xc7432180,21280919197,159864 1186747669.275792439: sched 2847,2846,0xc7432cb0,-7520203 1186747669.275820819: update_curr 0xc7432ce0,29238,-130625,21289429785,1,-7680067 1186747669.275821109: dequeue_entity 0xc7432ce0,21296593783,1 1186747669.275821763: enqueue_entity 0xc7432ce0,21297109852,1 1186747669.275826887: update_curr 0xc7432ce0,5772,5772,21289435557,1,-7680068 1186747669.275827652: enqueue_entity 0xc7fb0ca0,21281435557,639881 1186747669.275829826: update_curr 0xc7432ce0,1549,-318391,21289437106,319941,-8000000 1186747669.275831584: sched 2846,2849,0xc7fb0c70,8000000 About the values: update_curr: sched_entity, delta_fair, delta_mine, fair_clock, sleeper_bonus, wait_runtime (final values at the end of __update_curr) {en,de}queue_entity: sched_entity, fair_key, sleeper_bonus (at the start of __enqueue_entity/__dequeue_entity) sched: prev_pid,pid,current,wait_runtime (at the end of scheduling, note that current has a small structure offset to sched_entity) It starts with a timer task going to sleep, the busy loop runs for a few usec until the timer tick, the next timer task is woken up (sleeper_bonus is increased). Before switching the tasks, current task is updated and it's punished with the sleeper_bonus. These tests are done without the recent updates, but they don't seem to change the basic logic. AFAICT the change to __update_curr() only makes it more unpredictable, which task is punished with the sleeper_bonus. So again, what is this logic _supposed_ to do? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
