pcp
[Top] [All Lists]

Re: [pcp] pmrep: rename -R to -W

To: myllynen@xxxxxxxxxx
Subject: Re: [pcp] pmrep: rename -R to -W
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 13 Dec 2015 23:38:44 -0500 (EST)
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <566D93D8.9010109@xxxxxxxxxx>
References: <566D93D8.9010109@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: /5HwyRyfc/6nmcZNiNaNJvYDfL6wOg==
Thread-topic: pmrep: rename -R to -W

----- Original Message -----
> Hi,
> 
> related to the earlier raw/rate patches, the patch below renames -R to
> -W in case we'd want to support requesting rates also for non-counters
> in future (-W is not as good as -R for runtime but OTOH having -r/-R
> available for raw/rate is nice).

Hmm, this looks alot like -T with a relative end point.  So, we should
not need neither of these (-R / -W) options ...?  (the pcp.pmcc module
handles this all transparently, correctly - we shouldn't be attempting
to handle this logic at the script/application level, long-term).

$ pcp iostat -t 1sec -T 2sec
# Device      rrqm/s  wrqm/s    r/s    w/s    rkB/s    wkB/s avgrq-sz avgqu-sz  
 await r_await w_await %util
sda              0.0     0.0    0.0    4.0      0.0     20.0     5.00     0.03  
   7.5     0.0     7.5   1.5
$ pmrep -t 1sec -T 2sec hinv.ncpu
  h.ncpu
        
     N/A
       4
       4
       4
       4
       4
^C
(loops forever, which is not quite right)

Perhaps the right thing to do here is to just remove this command
line option at this stage, and implement -T more completely next
release (via proper high-level API use, deleting much pmrep code
in the process, hopefully).


As we discussed elsewhere, we need to start getting regression test
coverage of these patches too - anything this week will need to be
regression tested, but in general it'd be good to see pmrep changes
start arriving with test cases.

cheers.

--
Nathan

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