Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf_samuelsson@telia.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Performance measurement: Building openembedded-core with and without overclocking on C-i7 2600K
Date: Sun, 23 Oct 2011 23:50:06 +0200	[thread overview]
Message-ID: <4EA48C0E.6070700@telia.com> (raw)
In-Reply-To: <201110232150.53072.roman@khimov.ru>

2011-10-23 19:50, Roman Khimov skrev:
> ? ????????? ?? 18 ??????? 2011 10:03:25 ????? Ulf Samuelsson ???????:
>> Also what happens if it it built on a fast SSD, or even a RAMdisk?
> Our main build server has two Xeons X5670 with 96 GB of RAM. It's running 24×7
> cyclicly doing clean isolated builds of all our OE projects (currently five).
> "Isolated" means that the the actual build is done inside a container (LXC)
> with no network available at all, that is a requirement for all our builds, to
> be able to take one tarball of sources, one tarball of OE tree and build the
> project somewhere in a nuclear bunker.
>
> The system is configured in such way that container is located on tmpfs (with
> size of 50 GB). The most complex build takes about hour and a half on this
> system occupying about 45 GB of space in a ramdisk.
>
> So today I tried to get some RAM vs. Linux cache statistics and switched this
> mount point over to newly created 60 GB LVM partition with ext4 on RAID0 array
> consisting of two SAS 15K drives.
>
> The system made builds for three projects is this configuration and I see no
> difference at all, usual 1-2 minutes deviation. Granted, the system has quite
> powerful disks (RAID array gives about 380 MB/sec on hdparm) and things might
> be a little different on plain SATA drives, but frankly I'd expected to see
> the difference anyway since there are lots of small files involved in a build.
>
> Maybe I should try to further degrade the disk system by creating some
> encrypted volume inside LVM, but still from what I see Linux caching and
> buffering works good enough, just give it as much RAM as you can.
>
> But then also what you'll get from RAM or disk or even CPU upgrade depends on
> what type of build you have. Upgrading developers build servers from pair of
> 4-core Opterons (don't remember exact model) with 8 GB of RAM to pair of Xeons
> E5620 with 24 GB of RAM with comparable disks gave about 20-30% of build time
> reduction for one project and 50% for another. But that builds are not
> isolated and use icecc cluster with all build servers available to the
> cluster, maybe that helps also in our situation.
>

Thanks,

I tried installing 32 bit Ubuntu 11.10 on a HDD and got results,
which are very close to the results of 64 bit ubuntu 11.10, but when I tried
hdparm the 32 bit system had 50 MB/s and the 64 bit system
had 100-110 MB/s so they are not comparable.

Also tried putting tmp/sysroots on a 3 GB tmpfs, and that only
made the build a couple of minutes faster on a 1 hour build.



>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Best Regards
Ulf Samuelsson



  reply	other threads:[~2011-10-23 21:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-17 20:44 Performance measurement: Building openembedded-core with and without overclocking on C-i7 2600K Ulf Samuelsson
2011-10-17 22:13 ` Khem Raj
2011-10-18  6:03   ` Ulf Samuelsson
2011-10-18 14:44     ` Khem Raj
2011-10-18 14:47     ` Phil Blundell
2011-10-18 22:34       ` Ulf Samuelsson
2011-10-23 17:50     ` Roman Khimov
2011-10-23 21:50       ` Ulf Samuelsson [this message]
2011-10-29 14:23       ` Raffaele Recalcati
2011-10-18  6:28 ` Anders Darander
2011-10-18 12:05   ` Ulf Samuelsson
2011-10-18 12:19     ` Anders Darander
2011-10-18 13:40       ` Ulf Samuelsson

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=4EA48C0E.6070700@telia.com \
    --to=ulf_samuelsson@telia.com \
    --cc=openembedded-devel@lists.openembedded.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