[ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

[Ove Kaaven]

tir, 31.08.2004 kl. 05.23 skrev michael at cherryblossom.homelinux.com:
> 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.