tir, 31.08.2004 kl. 05.23 skrev [EMAIL PROTECTED]: > On Mon, Aug 30, 2004 at 08:52:04AM +0200, Ove Kaaven wrote: > > It's not. Linux only allows non-root processes to reduce its priority, > > not increase it, even for non-real-time priorities. Windows, however, > > allows it for non-real-time priorities. > > So the current priority would be the highest priority supported by the > user or process, unless running as root. Hm.
Maybe, if you want to look at it that way... > And I suppose that non-root processes can't decrease priority of other > processes (that aren't threads of said process) owned by the user it's > running under to simulate a higher-priority, or that it would be a bad > idea, right? It's possible, but it would be a bad idea for two reasons. 1) It'd mean that everything the user runs would on average get a lower scheduling priority than things run by other users. That's not necessarily what we want. 2) After you've reduced a thread or process's priority, it's not possible to elevate it to the original level again (without being root), so if a thread is set to low priority temporarily, it won't be possible to restore it to normal priority under Linux. Under Windows it's of course possible. > Does renice count as a process run under said user that > changes the priority of a process? I don't understand the question. > I suppose there's also the idea of having a single root process or > daemon (probably which would be an optional component) to "increase > performance" by "allowing wine to increase it's priority" by sending the > a said process or daemon a message or signal to tell it to increase the > priority of (a) wine process(es). Of course, if this is a reality, then > we have to debate over whether we want this installed by default, how it > would be configured, communication mechanisms (i.e. Signals, such as > USRSIG1, Unix Sockets, or IP Sockets), coding style, how interrupts and > whatnot are handled, how the daemon can be efficcently designed... And > then what about people who complain about having too many daemons to > configure and run on their Linux system to do basic tasks... We've toyed with the idea. > What about emulating this increasible priority, at the risk of lowering > wine's performance? Keep the actual real linux priority the same, but > do sleep cycles or slow down the process in some way so that by default > processes run at "Normal", at like, say, 75% (or whatever is the > accepted Windows computed CPU usage) of the thread's assigned/capable > processing power, and then "Idle" or "Low" only running if no other > threads (within wine, or in general) are using the CPU, and then "High" > using 100% of the thread's power? Or are you guys already saying this? The only reliable way to force a sleep cycle is by sending signals. But that's something I suggested in my other post. Note that Windows doesn't compute CPU usage. It just assigns all available CPU time to the highest priority thread that isn't sleeping (doing a round-robin only if there's more than one thread on that priority level), whether it's real-time-priority or idle priority.