| 1 |
On Sunday 04 March 2007 16:09:03 Duncan wrote: |
| 2 |
> Peter Humphrey <prh@××××××××××.uk> posted |
| 3 |
> 200703041151.37846.prh@××××××××××.uk, excerpted below, on Sun, 04 Mar |
| 4 |
> |
| 5 |
> > What is the machine doing? |
| 6 |
> |
| 7 |
> There's a couple things to check. First, you say /tmp is on tmpfs and in |
| 8 |
> memory (no swap), but you don't mention where you have $PORTAGE_TMPDIR |
| 9 |
> pointed. |
| 10 |
|
| 11 |
It's not long since we discussed this. It's set to /tmp, and so is |
| 12 |
PKG_TMPDIR. |
| 13 |
|
| 14 |
> Second, for general disk access speed (IOW, not portage specific), if |
| 15 |
> you've not checked it, emerge hdparm if necessary and see if your hard |
| 16 |
> drives are using DMA. If they aren't, you'll have MUCH slower disk i/o. |
| 17 |
|
| 18 |
Hdparm is installed and does set DMA on. The only disk access I can foresee |
| 19 |
portage doing is to write its log file. Could that really consume as much |
| 20 |
time as I'm seeing? Seems unlikely to me. |
| 21 |
|
| 22 |
[Later...] I've now found that if I run "hdparm -d1 /dev/sda" from an X |
| 23 |
terminal I get "HDIO_SET_DMA failed: Inappropriate ioctl for device", but |
| 24 |
when /etc/init.d/hdparm is run during boot I see [ok] for each drive. Looks |
| 25 |
like I've got some exploring to do. |
| 26 |
|
| 27 |
> Of course, also note that depending on the ebuild stage and how much of |
| 28 |
> what it is accessing you already have cached, portage does do some non- |
| 29 |
> tmp I/O access. |
| 30 |
|
| 31 |
As I said, I was watching firefox being compiled. All the preliminary stages |
| 32 |
had been completed by then. All the source code should have been in memory, |
| 33 |
but I can't say the same for any other libraries. On the other hand, just |
| 34 |
how much time is needed to load all the development libraries needed for |
| 35 |
this compilation? |
| 36 |
|
| 37 |
> There's also portage logging and associated log variables. Again, this |
| 38 |
> shouldn't be a big deal if you've got DMA on your drives, but it might be |
| 39 |
> if you don't. |
| 40 |
|
| 41 |
Yes, that's the only thing I can think of. |
| 42 |
|
| 43 |
> Finally, if it's writing anything to NFS mounts or the like over the |
| 44 |
> network, or if you have distcc active, it's possible the wait is on the |
| 45 |
> network, not on your local hard drives, of course depending on exactly |
| 46 |
> how you are configured. |
| 47 |
|
| 48 |
I did play with distcc but found it unreliable on a large package, so I've |
| 49 |
removed it from make.conf. I don't use NFS or any other networked |
| 50 |
operations that I can think of. |
| 51 |
|
| 52 |
Thanks for the suggestions. |
| 53 |
|
| 54 |
-- |
| 55 |
Rgds |
| 56 |
Peter |
| 57 |
-- |
| 58 |
gentoo-amd64@g.o mailing list |
Archives