1 |
On Fri, Sep 30, 2011 at 10:28 AM, Paul Hartman |
2 |
<paul.hartman+gentoo@×××××.com> wrote: |
3 |
> On Fri, Sep 30, 2011 at 11:25 AM, Mark Knecht <markknecht@×××××.com> wrote: |
4 |
>> Hi, |
5 |
>> Is there a portage option that will limit the number of cores used |
6 |
>> by emerge? For instance, in a chroot on a 12 core machine I want to |
7 |
>> limit emerge to not using more than 3 cores? |
8 |
>> |
9 |
>> If possible, I'd also like to limit the total disk bandwidth |
10 |
>> consumption during emerge. For instance, when untarring a big file to |
11 |
>> do the emerge at times the disk consumption gets to high and the |
12 |
>> machine becomes laggy. Is there an option that addresses this? |
13 |
>> |
14 |
>> These questions are mostly about being able to update a chroot |
15 |
>> mid-day without other tasks slowing down too much. I don't care how |
16 |
>> long the chroot really takes to get a huge emerge done, but rathe just |
17 |
>> keeping the machine very responsive while it's happening. I already |
18 |
>> use: |
19 |
>> |
20 |
>> MAKEOPTS="-j3" |
21 |
>> PORTAGE_NICENESS="15" |
22 |
>> |
23 |
>> which helps (I think) but it doesn't totally address either of the issues above. |
24 |
> |
25 |
> If your MAKEOPTS is -j3 then it's not going to use more than 3 cores |
26 |
> at a time but it will touch all 12 cores throughout the process |
27 |
> because of the normal load balancing. If you want it to use only 3 |
28 |
> specific cores, you would need to set the processor affinity (usually |
29 |
> done using the "taskset" command from sys-apps/util-linux). |
30 |
> |
31 |
> For the disk I/O you can set an ionice in your make.conf like: |
32 |
> PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}" |
33 |
> |
34 |
> Salt to taste. :) |
35 |
> |
36 |
|
37 |
Thanks to all who have answered so far. I'll give the ionice command a |
38 |
try immediately. I'll try to address my view of other comments in a |
39 |
single post to keep the traffic down. |
40 |
|
41 |
My experience with -j3 is not that it limits emerge to 3 CPU cores but |
42 |
rather it limits emerge to running 3 _jobs_. There's a big difference. |
43 |
1 job can use 12 cores if gcc spawns a lot of stuff in parallel, which |
44 |
in my experience it does. It's this parallel spawn running up to 12 |
45 |
cores in use which causes the machine to lag. Even when not setting |
46 |
the -j option at all which results in a single package being emerged |
47 |
at one time, I often use 6-12 cores in use for short periods of time |
48 |
as gcc builds that package. This is completely appropriate for the |
49 |
host machine. When I do updates I want them to get done ASAP. On the |
50 |
other hand, for a chroot it's too much power. |
51 |
|
52 |
Concerning which core is used, I don't care. |
53 |
|
54 |
Concerning the 'bouncing around' aspect of multi-core processors, |
55 |
that's primarily a CPU function of where it has cached data & code as |
56 |
well as thermal management on chip. Internal hardware is generally |
57 |
controlling what CPU gets used for what as far as I know. However even |
58 |
a single emerge job (1 package being emerged) could move around from |
59 |
core to core depending on what work is getting done. It's |
60 |
understandable that a driver might be fundamentally associated with a |
61 |
specific core's immediate L1 or L2 cache, whereas the emerge job |
62 |
itself could be using other cores. |
63 |
|
64 |
Of course, everything above is just my limited understanding of what |
65 |
the hardware is doing and could be completely wrong. |
66 |
|
67 |
Thanks, |
68 |
Mark |