On 4/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Basically this hack is bad on policy grounds because it is giving X an "legislated, unfair monopoly" on the system. It's the equivalent of a state-guaranteed monopoly in certain 'strategic industries'. It has some advantages but it is very much net harmful. Most of the time the "strategic importance" of any industry can be cleanly driven by the normal mechanics of supply and demand: anything important is recognized by 'people' as important via actual actions of giving it 'money'. (This approach also gives formerly-strategic industries the boot quickly, were they to become less strategic to people as things evolve.)
If you're going to drag free-market economics into it, why not actually use the techniques of free-market economics? Design a bidding system in which agents (tasks) earn "money" by getting things done, and can use that "money" to bid on "resources". You will of course need accurate cost accounting in order to decide which bids are most "profitable" for the scheduler to accept, and accurate transfer accounting to design price structures for contracts between agents in which one agrees to accomplish work on behalf on another. Actual revenues come from doing the work that the consumer wants done and is willing to pay for. Etc., etc. Has your horsepucky filter kicked in yet? If your system doesn't work this way -- perhaps because you think as I do that scheduler design is principally an engineering problem, not an economics problem -- then analogies from economics are probably worth zip. Yes, I wrote earlier about "economic dispatch" -- that's an operations problem, a control theory problem, an _engineering_ problem, that happens to have a set of engineering goals and constraints that take profitability into account. I think you might be able to design a better Linux scheduler anchored in the techniques and literature of control theory, perhaps specifically with reference to electric-utility economic dispatch, because the systems under control and the goals of control are similar. But there's a good reason not to treat X as special. Namely, that it _isn't_. It may be the only program on many people's Linux desktops with an opaque control structure -- a separate class of interactive activities hidden inside an oversubscribed push-model pipeline stage -- but it's hardly the only program designed this way. Treat the X server as a easily instrumented exemplar of a event-loop-centric design whose thread structure doesn't distinguish between fast-twitch and best-effort activity patterns. I wrote earlier about what one might do about this (attach urgency to to the work in the queue instead of the worker being asked to do it). Cheers, - Michael - 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/
