Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Weird and unpredictable problem: emerge grinds system to a halt
Date: Thu, 28 Sep 2006 07:49:19
Message-Id: effuks$fi$2@sea.gmane.org
In Reply to: Re: [gentoo-amd64] Weird and unpredictable problem: emerge grinds system to a halt by Daniel Iliev
1 Daniel Iliev <danny@××××××××.com> posted 451B6C1E.8020503@××××××××.com,
2 excerpted below, on Thu, 28 Sep 2006 09:30:54 +0300:
3
4 > Petter Haggholm wrote:
5 >> The subject is fairly descriptive. Often -- but not always -- an
6 >> emerge will render my system unusable. At a PORTAGE_NICENESS of 3, and
7 >> fairly standard MAKEOPTS of "-j2" (on a single-core system), I'm ...
8 >> well, rather surprised, confused, and very frustrated. [] The system
9 >> becomes unresponsive, the mouse will move but with enough of a lag that
10 >> physically moving it may not cause a cursor movement for the next 30
11 >> seconds or so, clicking a taskbar window may not have an effect at all;
12 >> sometimes I can't even ssh into the system from my other computer (to
13 >> kill the emerge) because it's slow enough that the ssh daemon times out
14 >> my login attempt. This never used to happen[.]
15 >>
16 > 2) What happens if you put PORTAGE_NICENESS=19, MAKEOPTS of "-j2 -l1" ?
17 > l5 (small "L", not the number "one"), means "loadavg=<1" If loadavg goes
18 > up to 1 make waits this level to drop before continuing its job
19 > 3) Is DMA enabled for your HDD(s)? (hdparm -d1 /dev/xxx)?
20
21 I second those two suggestions.
22
23 It never used to happen? I'll just /bet/ you somehow disabled hard drive
24 DMA access. In addition to checking hdparm, ensure that you have the
25 correct drivers for your hard drive chipset being compiled with the kernel
26 and verify from your log (or dmesg) that they are loaded and active -- the
27 kernel isn't loading generic drivers that grab the hardware first so the
28 chipset specific drivers can't grab the hardware themselves.
29
30 It's almost certainly I/O access in any case, so portage niceness probably
31 won't do a lot of good, tho reducing to -j1 or -j2 -l1 or -j1 -l1 might
32 help some. You can also try different I/O and task schedulers, and tweak
33 your kernel preemption settings.
34
35 How much RAM do you have? If > 3.5 GB, you may have IOMMU issues as well.
36 I can describe that in more detail but won't bother here since I don't yet
37 know that you'd be affected yet, which you won't be if you have less than
38 3.5 GB RAM.
39
40 Another thing you can do if you have a lot of RAM (I'd suggest >=4 gig) is
41 make /tmp or /var/tmp (whatever you have $PORTAGE_TMPDIR set to) a tmpfs,
42 so all those temporary files that gcc and emerge create during the emerge
43 process stay in RAM. I have 8 gigs of RAM and do this. It makes a pretty
44 big difference in both emerge time and system responsiveness while I'm
45 merging, since there's so much less disk activity.
46
47 --
48 Duncan - List replies preferred. No HTML msgs.
49 "Every nonfree program has a lord, a master --
50 and if you use the program, he is your master." Richard Stallman
51
52 --
53 gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: Weird and unpredictable problem: emerge grinds system to a halt Petter Haggholm <petter@×××××××××××.ca>