On Tuesday 06 March 2007 05:23, Al Boldi wrote: > Con Kolivas wrote: > > Gears just isn't an interactive task and just about anything but gears > > would be a better test case since its behaviour varies wildly under > > different combinations of graphics cards, memory bandwidth, cpu and so > > on. > > What about reflect? It has the same problem. > > > I'm not even sure what you're trying to prove with gears. > > RSDL fairness. > > Ok, try this: > # gears & gears & > Both run smoothly. > # nice gears & nice gears & > Both run smoothly. > > Now: > # gears & nice -10 gears & > Both stutter. > > But: > # gears & nice --10 gears & > Both run smoothly. > > Something looks fishy with nice levels.
Hah I just wish gears would go away. If I get hardware where it runs at just the right speed it looks like it doesn't move at all. On other hardware the wheels go backwards and forwards where the screen refresh rate is just perfectly a factor of the frames per second (or something like that). This is not a cpu scheduler test and you're inferring that there are cpu scheduling artefacts based on an application that has bottlenecks at different places depending on the hardware combination. To imply something is fishy with nice levels, do a test that _only_ uses cpu (and not the bus, memory bandwidth, the gpu and has driver interactions) and prove that there is something wrong. What happens to other resources on the machine the cpu scheduler has no control over. The -rt tree tries to address these factors for example but it's a huge - some would say insurmountable - thing to try and manage at all levels on a general purpose operating system. The cpu is proportioned out very fairly with rsdl on both quota and latency according to nice vs cpu usage. When something is fully cpu bound on rsdl its average and maximum latency will be greater than something that only intermittently uses cpu. The (somewhat lengthy and not easily digestible) docs describe how you can model what these latencies will be. > Otherwise, your scheduler looks great! Thanks! -- -ck - 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/
