You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Ian Downes (JIRA)" <ji...@apache.org> on 2013/09/11 07:13:51 UTC
[jira] [Commented] (MESOS-687) slave should export perf hardware
counters when available
[ https://issues.apache.org/jira/browse/MESOS-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763996#comment-13763996 ]
Ian Downes commented on MESOS-687:
----------------------------------
Yes, this is something we'll be working on. Initially, we'd like to get it instrumented and capturing data so we can be more data-driven when improving our machine level isolation and to help diagnose interference issues. Beyond that there are indeed lots of interesting ideas about incorporating this into higher level scheduling decisions across machines.
> slave should export perf hardware counters when available
> ---------------------------------------------------------
>
> Key: MESOS-687
> URL: https://issues.apache.org/jira/browse/MESOS-687
> Project: Mesos
> Issue Type: Story
> Components: slave
> Reporter: brian wickman
> Priority: Minor
>
> It would be very valuable for the slave resource monitor to export hardware counters. There are a few ways this could be done -- either by invoking perf directly or by accessing the counters via the syscall/read interface described by http://lxr.free-electrons.com/source/tools/perf/design.txt I'd imagine this would just get plumbed through Isolator::usage in the end and get exported via the resource monitor endpoint.
> Correct me if I'm wrong but there's currently no information exposed (programmatically) at the granularity level of executor, so I don't really know how this information could ever make its way into the hands of a scheduler for the purpose of making better scheduling decisions vis-a-vis things like task-level interference. Given Google's CPI paper (http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/40737.pdf) it sounds like something worth investigating.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira