William Cohen

William Cohen has been a developer of performance tools at Red Hat for over a decade and has worked on a number of the performance tools in Red Hat Enterprise Linux and Fedora such as OProfile, PAPI, SystemTap, and Dyninst.

William Cohen's contributions

data layout
Article

How data layout affects memory performance

William Cohen

This article explains what developers need to know about modern computer memory and how data layout can affect memory performance.  

Red Hat Developer
Article

Algorithms != Programs and Programs are not "One size fits all"

William Cohen +1

Big-O analysis doesn't always yield the best real world performance. There is likely a mismatch between the mental model taught in school and actual hardware. Part 1 of a series on understanding performance in modern computing.

SystemTap
Article

Making the Operation of Code More Transparent and Obvious with SystemTap

William Cohen

You can study source code and manually instrument functions as described in the “Use the dynamic tracing tools, Luke” blog article, but why not make it easier to find key points in the software by adding user-space markers to the application code? User-space markers have been available in Linux for quite some time (since 2009). The inactive user-space markers do not significantly slow down the code. Having them available allows you to get a more accurate picture of what the...

SystemTap
Article

"Use the dynamic tracing tools, Luke"

William Cohen

Reviewing source code can be helpful in understanding how code works, but the static view may not give you a complete picture. The paths taken through code are heavily data dependent. Learn how to use Systemtap and debuginfo to dig into the Ruby interpreter internals on Red Hat Enterprise Linux 7.

Article Thumbnail
Article

Find what capabilities an application requires to successful run in a container

William Cohen

Many developers would like to run their existing applications in a container with restricted capabilities to improve security. However, it may not be clear which capabilities the application uses because the code uses libraries or other code developed elsewhere. The developer could run the application in an unrestricted container that allows all syscalls and capabilities to be used to avoid possible hard to diagnose failures caused by the application's use of forbidden capabilities or syscalls. Of course, this eliminates the...