On Fri, 2017-08-18 at 11:04 +0300, Markus Lehtonen wrote:
> Hi,
>
Ok so basically I wasted my time on this profiling exercise. Thanks for
the clarification.
> Using selftest to measure the signing performance is fruitless. The effect of
> using "chunks" really depends on the number of subpack
Hi,
Using selftest to measure the signing performance is fruitless. The effect of
using "chunks" really depends on the number of subpackages the recipe produces.
Selftest uses one of the smallest recipes , i.e. "ed", so you won't see any
difference. But with hundreds of subpackages you get dif
On Thu, 2017-08-17 at 10:50 +0300, Markus Lehtonen wrote:
> Hi,
>
> I quickly run some tests on a Xeon server, using glibc-locale as the recipe
> to build.
> 100: 154s
> 10: 162s (+5%)
> 1: 234s (+51%)
What I did to measure parallel versus serial is to run the corresponding
selftest (signing.Si
Hi,
I quickly run some tests on a Xeon server, using glibc-locale as the recipe to
build.
100: 154s
10: 162s (+5%)
1: 234s (+51%)
Even if signing is not parallel, the difference may be explained by the number
of rpm processes that get spawned. I would drop the factor to 10 or use
BB_NUMBER_TH
On Wed, 2017-08-16 at 15:28 +0300, Markus Lehtonen wrote:
> I agree. I don't see reason for dropping parallelism completely. There is a
> real gain when running on beefier machines. Making it configurable would
> probably be best. Or just drop it to a saner value, like 20 or 10.
>- Markus
>
On Wed, Aug 16, 2017 at 5:28 AM, Markus Lehtonen
wrote:
> I agree. I don't see reason for dropping parallelism completely. There is a
> real gain when running on beefier machines. Making it configurable would
> probably be best. Or just drop it to a saner value, like 20 or 10.
Deriving a value
I agree. I don't see reason for dropping parallelism completely. There is a
real gain when running on beefier machines. Making it configurable would
probably be best. Or just drop it to a saner value, like 20 or 10.
- Markus
On 16/08/2017, 2.53, "Mark Hatle"
wrote:
It would probably be
It would probably be better if this was configurable with a 'safe' default.
Moving from parallel to single will greatly affect the overall performance on
larger build machines (lots of memory and cores) that can handle the load vs a
typical development machine.
--Mark
On 8/15/17 4:40 PM, leonard
From: Leonardo Sandoval
gpg signing in file batches (which was default to 100) is a memory expensive
computation, causing trouble in some host machines (even on production AB
as seen on the bugzilla ID). Also, in terms of performance, there is no real
gain when rpm signing is done in batches. Con
