[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
>>> <robertbartlettbaron@gmail.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 &'))?
>>>
>>> Thanks,
>>>
>>> "&" 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
> calculations).

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. ;)

-- 
Stan


Reply to: