[Darshan-users] Computation of CP_ACCESS[1-4]_ACCESS and other histogram counters

Matthieu Dorier matthieu.dorier at irisa.fr
Fri Feb 28 02:58:41 CST 2014


Thanks Rob and Phil for your answers!

Best,

Matthieu Dorier 
PhD student at ENS Rennes 
http://people.irisa.fr/Matthieu.Dorier 
----- Mail original -----
> De: "Phil Carns" <carns at mcs.anl.gov>
> À: darshan-users at lists.mcs.anl.gov
> Envoyé: Jeudi 27 Février 2014 18:17:29
> Objet: Re: [Darshan-users] Computation of CP_ACCESS[1-4]_ACCESS and other histogram counters
> 
> On 02/27/2014 12:04 PM, Latham, Robert J. wrote:
> > On Thu, 2014-02-27 at 14:30 +0100, Matthieu Dorier wrote:
> >> Hi,
> >>
> >> Simple questions out of curiosity:
> >> I see some counters like, for instance, CP_ACCESS[1-4]_ACCESS (described
> >> as "4 most common access sizes"). Does it mean that for each file
> >> accessed, Darshan will keep in memory a full histogram of all the access
> >> sizes until the end of the program, to be able to get the most frequent
> >> ones when writing the log file? If so, isn't it memory-consuming in case
> >> of a large number of accesses with different sizes? Besides, why 4? Is it
> >> motivated by some analysis that showed 4 to be good enough for most
> >> applications?
> >>
> > Darshan does keep a histogram, as you've seen, but the space for that
> > histogram is bounded by the number of buckets -- and the buckets are
> > fixed.
> >
> > The ACCESS counters come from simply a Most Frequently Used list with
> > four slots.  Again, bounded by the number of slots no matter how crazy
> > the access pattern might be.
> >
> 
> At runtime each process actually uses a tree data structure to track the
> most frequent access and stride sizes- we track those particular values
> specifically rather than using a histogram.  The tree for each is capped
> at 32 elements.  At finalize time it then picks the top 4 to store in
> the counters.  If the file is shared across all processes then a
> reduction operator continues to do its best to keep the top 4 as file is
> reduced to a single record.
> 
> The good news is that the memory consumption is bounded.  The down side
> is that in the degenerate case (an application that uses more than 32
> access sizes per file, or a shared file in which each rank used entirely
> different access sizes) then those particular counters might be
> under-reported.  In practice we haven't really seen that happen, though.
> 
> The "most frequently used" counters are recorded independently of the
> histogram fields.  The histograms should never be misreported, even in
> extreme cases.  We can retain all of the histogram bins all the way
> through runtime and reduction.
> 
> I don't think we have any formal rationale for why we chose to report 4,
> we just picked it :)
> 
> thanks,
> -Phil
> _______________________________________________
> Darshan-users mailing list
> Darshan-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/darshan-users
> 


More information about the Darshan-users mailing list