Re: thread issue
On 8/4/2011 10:33 AM, Darac Marjal wrote:
> On Thu, Aug 04, 2011 at 10:28:01AM -0500, Stan Hoeppner wrote:
>> On 8/4/2011 9:40 AM, lina wrote:
>>> On Thu, Aug 4, 2011 at 10:29 PM, Robert Baron
>>> <email@example.com> wrote:
>>>> have you tried adding an '&' to the tasks you think can be run in
>>>> parallel (as in running them in the background (ie 'mycmd myargs &'))?
>>> "&" is cool.
>>> now is fully running, but, there is another thing slow it down, the
>>> nice level is 19. why is it so high? are there some root's setting?
>> Nice levels can be deceiving to those who don't understand how kernel
>> scheduling works. For example, it is possible, and happens all the time
>> really, that a program with a nice level of 19 will fully consume 100%
>> of a processor's time until the program completes.
>> The only time nice comes into play is when scheduling contention exists.
>> This only occurs when there are more ready-to-run processes/threads
>> than available processor time slice slots. On an 8 processor desktop
>> with the default 1000Hz scheduler you have 8,000 scheduling slices per
>> second. So unless your system has 8,001 ready to run processes every
>> second, that nice level 19 process will get all the CPU time it needs.
>> Nice is a relic of early UNIX when businesses and universities would
>> have dozens to hundreds of concurrent users on serial TTY terminals
>> running programs on a shared single processor machine. Nice allowed
>> administrators to provide "fair" access to all users, or to make sure a
>> critical batch job got the cycles it needed, even with many users
>> running their programs. On today's multi-core desktops, nice is
>> literally irrelevant. This is actually the case for most business
>> UNIX/Linux systems as well, as almost all of them have excess processor
>> capacity for their actual workloads.
> I wouldn't say that nice is completely irrelevant. I run BOINC on my
> desktop machine and rely on the BOINC tasks having more nice (if I can
> take the opportunity to butcher English) than other tasks such as the
> web browser, the window manager and so on.
> Doing so also allows me to tell my CPU scheduler to ignore niced
> processes and only spin up the CPU to full speed when an important task
> wants it (as opposed to always running at full speed doing the BOINC
Thanks for pointing out the exception to the rule. I would think
affinity (taskset) is likely more popular with BOINC users than nice,
though. I guess you simply don't want an idle core, ever. Must be hard
on your electric bill. ;)