All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Tom Rini <tom_rini@mentor.com>
Cc: poky@yoctoproject.org
Subject: Re: requesting input on specs for a new Poky build server
Date: Wed, 20 Apr 2011 08:23:27 -0700	[thread overview]
Message-ID: <4DAEFA6F.3010503@linux.intel.com> (raw)
In-Reply-To: <4DA396CF.4080804@mentor.com>



On 04/11/2011 05:03 PM, Tom Rini wrote:
> On 04/11/2011 02:50 PM, Joe Sauer wrote:
>> I have the pleasure of spec'ing out a new server for doing Poky builds
>> (we are at Green 3.3.1).  As a reference point, my desktop machine is a
>> quad-Xeon @ 2.5 GHz with 4GB of RAM and SATA disk.  I can do a full
>> "clean" build for our LabQuest (armv5te) in 2 hours.
>>
>> Here are some questions I would like to get feedback on regarding a
>> build server:
>>
>> 1.  Would I get better build time going with more procs (8?) or faster
>> procs (3+ GHz)?

I would go with more CPUs before I went with faster CPUs (at least from
2.5 to 3.3). Poky builds scale nicely to at least 16 physical cores (ie
4 quad-cores, hyperthreading is effective as well, but not so much as
physical cores), so until you get to that point, more is better in my
opinion.

>>
>> 2.  Are SATA drives OK, or should I go with RAID to get better R/W
>> performance?

A RAID 0 array of SATA drives is your best performing option (short of a
RAID 0 SSD array). You have to trade this extra performance for lower
reliability. RAID 0 has no redundancy, if one drive fails, all your data
is gone - so only keep recreatable data on the RAID array. I'd start
without RAID and test, see if you are maximizing your IO bandwidth.

>>
>> 3.  If I have to choose one or the other, should I go with faster procs
>> or faster disk I/O?

Provided you have a reasonably decent SATA controller on board, I'd opt
for _more_ procs.

> 
> If you're on somewhat of a budget, the general rule of thumb about going
> for last months fastest processor (as opposed to the one just released)
> is probably a wise bet.  And you probably want 8-12GB ram if you can fit it.
> 
> The only real and not always obvious trick is if you can afford an SSD
> (and afford to kill it and replace it every so often) doing your builds
> there is a real big win.

The failures are the scary part as you mentioned. I keep my git
repositories and downloads on an SSD and do my builds on a 2 disk RAID
array. I usually see either build dependencies or CPU as the bottleneck
before IO.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


  reply	other threads:[~2011-04-20 15:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-11 21:50 requesting input on specs for a new Poky build server Joe Sauer
2011-04-12  0:03 ` Tom Rini
2011-04-20 15:23   ` Darren Hart [this message]
2011-04-18  8:46 ` Richard Purdie

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=4DAEFA6F.3010503@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=poky@yoctoproject.org \
    --cc=tom_rini@mentor.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.