SCIENTIFIC-LINUX-USERS Archives

April 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Vladimir Mosgalin <[log in to unmask]>
Reply To:
Vladimir Mosgalin <[log in to unmask]>
Date:
Thu, 5 Apr 2012 21:46:07 +0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
Hi Wil Irwin!

 On 2012.04.05 at 09:47:45 -0700, Wil Irwin wrote next:

> I'm convinced it has to be a kernel issue, but that doesn't explain why it
> was working 2 months ago with the previous kernel and then Monday (w/o any
> updates or changes), multiple terminal won't send jobs to multiple cores.
> 
> Does anyone have any idea what might me causing this. Suggest on how to
> further troubleshoot?

This is possible with cgroups (terminal gets some cgroup which is locked
to certain core by cpuset, then all children are locked too), but it
requires someone to actually set it up, it shouldn't happen on fresh
system or something like that.
If you suspect someone might have tweaked this system, check cgroups
documentation
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch-Using_Control_Groups.html
and cpuset documentation
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-cpuset.html
to see how processes are assigned to cgroups and how cgroups can be
cpuset-locked.

However, if this happens on fresh system, it might be something else.
Normally it's not even about terminal window - every process normally
has chance of using any CPU core, and scheduler spreads them more or
less evenly - even if you just run few background jobs from single
shell. It doesn't matter at all to scheduler if you are running
background process from same session or from multiple windows.
You might want to check if something else (not cgroup) was involved in
setting processes masks, by calling "taskset -p <pid>" for interesting
pids.

If they don't have special assigned affinity ('f' for 4-core host, 'ff'
for 8-core and so on), then, well, maybe something is wrong with
scheduler, or the way it picks cores for these processes..


-- 

Vladimir

ATOM RSS1 RSS2