All of lore.kernel.org
 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 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.