pcp
[Top] [All Lists]

Re: New pdubuf-related QA failures

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: New pdubuf-related QA failures
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Thu, 12 Mar 2015 21:00:51 -0400
Cc: Dave Brolley <brolley@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <819441861.5166899.1426194355778.JavaMail.zimbra@xxxxxxxxxx>
References: <1179164386.4369398.1426124282232.JavaMail.zimbra@xxxxxxxxxx> <5501AC9B.9080907@xxxxxxxxxx> <819441861.5166899.1426194355778.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

> > > 828 and 833 are new failures from overnight commits - they look
> > > likely to be just .out file issues [...]

Yes, sorry.  Both new .out.bad files should become .out.  (And I
could've sworn in one of my too-many rebases the 828 one was already
accounted for.)


> I mainly just want to make sure all bases were covered and since it
> touches some of the most critical code paths in all PCP (potentially
> regressing single-threaded performance, etc) that those questions were
> fully addressed.

> e.g. is live mode affected positively / negatively?

As per the other note, very slightly positively.  Memory consumption
should be slightly smaller (since buffers are neither
retained-after-free nor artificially enlarged).  Since live mode is
nowhere near cpu-bound, it's a hard phenomenon to measure.

> how much of those reported times was I/O time - are we CPU bound yet
> with warm cache?

With pmwebd or such bulk processing, it was all cpu-bound, so
representing the worst case scenario.

> were the reported numbers warm/cold cached archives,

With the pmwebd bulk numbers, warm caches.


- FChE

<Prev in Thread] Current Thread [Next in Thread>