public inbox for gentoo-embedded@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: gentoo-embedded@lists.gentoo.org
Cc: Christopher Friedt <cfriedt@visible-assets.com>
Subject: Re: [gentoo-embedded] slow compilation on NFS Root -> use an external USB hard disk ;-)
Date: Mon, 28 May 2007 14:27:25 -0400	[thread overview]
Message-ID: <200705281427.27335.vapier@gentoo.org> (raw)
In-Reply-To: <4659F417.5000404@visible-assets.com>

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Sunday 27 May 2007, Christopher Friedt wrote:
> Using the stage3 gentoo arm-softfloat-linux-uclibc filesystem, I had for
> some time been natively compiling packages for my target system, with
> the root located over NFS.
>
> Normally it wasn't so bad - sure it was quite slower than
> cross-compiling. But one thing I hated about cross compiling was
> randomly running into packages that use some sort of pkgconfig file that
> I didn't have present, or trying to run some native program in configure
> and coming up with an error.

ive found NFSv3 + TCP actually isnt so shabby ... you have to make sure to use 
those options in the kernel cmdline though as the default is NFSv2 + UDP

> When I got around to compiling the GNU Classpath (for use with jamvm,
> and stripped of all but the necessities), I found that compiling this
> app over an NFS root failed quite often because of out-of-memory errors.
> The process was killed outright. Then I read somewhere about creating a
> swap file on an NFS root, using losetup to create a loop device, and
> using swapon to load that swap into the kernel's VM. That turned out to
> be the worst idea I think I've ever had, because the overhead of using
> RPC with the NFS root was probably of O^2 complexity at that point,
> especially considering all of the swapping that had to be done with such
> a huge compile, using jikes of course.

this is the biggest problem and ive found not worth the hassle if possible ... 
doing network swap (whether it be via nbd or nfs or ...) is just not usable

if your machine doesnt have enough physical ram to compile w/out -pipe, then 
it's time to search for another option :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

  reply	other threads:[~2007-05-28 18:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-27 21:11 [gentoo-embedded] slow compilation on NFS Root -> use an external USB hard disk ;-) Christopher Friedt
2007-05-28 18:27 ` Mike Frysinger [this message]
2007-05-30 20:44   ` KiberGus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200705281427.27335.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=cfriedt@visible-assets.com \
    --cc=gentoo-embedded@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox