----- Original Message -----
> [...]
> > Another approach might be to run some code to attempt to saturate memory
> > bandwidth for a short time (perhaps using set_mempolicy(2) and cycling
> > through each node), then measure/export the max observed bandwidth? (or
> > at least, use that to set initial per-node values in the config file).
>
> Hmm, its a good idea, we can use "stream" to do that.
> But again, the theoretical max bandwidth will be something which
> will be difficult to saturate, even for the benchmark tools (like
> "stream"). Also, depending on the no. of nodes, it will take time to
> cycle, saturate and collect the observed max bandwidth.
*nod* - definitely not something to run all the time, and under relatively
controlled circumstances when it is run.
> > Either way, this is a fairly specialized domain so I guess it may be more
> > suited to a specialized PMDA rather than pmdalinux itself. The ./Install
> > script might prove a good place to run the memory test and populate those
> > initial config file values?
>
> Agreed. Will add a more specific pmda to find the max memory
> bandwidth metric.
> Can we put a check for the user if they want to proceed with the
> memory test (for the initialization of the config file) inside the Install
> script? That way, the user will have the choice to either populate
> the config file by themselves or by running some saturation tool
> (and hence, the user is aware of the risks).
Yes definitely - one can also ask for parameters interactively, if needed.
An example in PCP git that does similar things is src/pmdas/shping/Install
cheers.
--
Nathan
|