pcp
[Top] [All Lists]

Re: New pdubuf-related QA failures

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: New pdubuf-related QA failures
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 12 Mar 2015 17:05:55 -0400 (EDT)
Cc: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5501AC9B.9080907@xxxxxxxxxx>
References: <1179164386.4369398.1426124282232.JavaMail.zimbra@xxxxxxxxxx> <5501AC9B.9080907@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: sTXebIGtAC/B0dvc9V4bBdONAoqW2g==
Thread-topic: New pdubuf-related QA failures
Hey Dave,

----- Original Message -----
> On 03/11/2015 09:38 PM, Nathan Scott wrote:
> > Hi guys,
> >
> > 828 and 833 are new failures from overnight commits - they look
> > likely to be just .out file issues, but I see 828 at least has
> > already been looked at (but still fails).  833 might be a lack
> > of valgrind installed on your test machine? - looks like its got
> > incorrect .out from not being run anyway; .bad files attached.
> >
> > Also, ISTR at one point Ken asking for additional performance
> > data before this change was made, but don't remember seeing any
> > go past - was/is everyone content with this change?  Thanks.
> >
> Sorry, if this was premature. I had read Ken's responses to Frank's
> performance data as positive and I also read that Ken had pulled these
> changes and reviewed them favourably.

Yep, I don't think it was necessarily premature (except for those QA
failures :) - though I assume if Ken was finished with it, he'd have
merged it.

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?
how much of those reported times was I/O time - are we CPU bound yet
with warm cache?  were the reported numbers warm/cold cached archives,
is there more work to do? ... that sort of thing (well, that's what I
would be looking for, maybe Ken had other ideas).  More comprehensive
performance data I think is what Ken asked for, and I don't remember
seeing that so far, hence the follow-up - no big deal, I'm sure it'll
be forthcoming.

cheers.

--
Nathan

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