| Age | Commit message (Collapse) | Author |
|---|
|
This introduces vmon_proc_t.n_current_threads, a counter
reflecting the currently non-stale number of threads in an
is_threaded process.
You could get this by walking the threads linked list and
filtering out the is_stale entries, but in preparation of showing
this count in the charts hierarchy I'm caching the incrementally
maintained count so the list doesn't need to be walked
repeatedly.
Note it's important to suppress the is_stale nodes from the
count, so the count isn't being decremented when stale nodes get
finally removed from the list - instead when nodes transition to
being stale. The count shown in charts should reflect the number
of thread rows seen at the same time (when --no-threads isn't in
use)
|
|
--hide-threads needs a way to tell libvmon to both follow threads
and neglect to actually sample them.
Note this will still allocate the vmon_proc_t for every thread,
but conserves in the open proc files department by not
opening/reading everything other than the children proc file for
threads - regardless of what other proc wants have been specified.
So front-ends still need to traverse threads of processes, and if
they want to collapse the children of threads as if they're all
children of the threads' parent, that's up to the front-end to do
so. In the vwm/vmon case, that's a detail for charts.c to
handle, when --hide-threads is in effect. It will have to render
the children of threads as if they're children of the threads'
parent, to hide this clusterfuck from what's visible to the user.
|
|
The public callers of vmon_proc_monitor() shouldn't ever be
passing a non-NULL parent as that's a pretty intimate and messy
internal aspect of libvmon. So let's remove that altogether from
the public function for monitoring a process, and turn existing
one supporting parents into a libvmon-private function.
Trivial cleanup, there's so much more needed in libvmon since
it's the epitome of an organically evolved crusty thing.
|
|
It's handy to see what the libvmon hash table state of the world
is when trying to understand brokenness, but also as a tool for
verifying things aren't out of sync with what the hierarchical
view contains.
|
|
The current value of 128 doesn't really accomodate most the
systems I'm dealing with these days... bump to 1024.
|
|
Preparatory commit for enabling charts to apply % scaling to
non-threaded procesess, to make better use of the row's available
space.
A non-threaded process can't use more than a single core, so it
should be able to scale its %age out to the full row height. The
same will be applied to individual thread rows, as those can at
most use a single core.
The exception is a threaded process - its CPU %ages are
aggregate, and must represent up to the number of CPUs in the
system within their row.
|
|
Preparatory commit for enabling charts that scale per-thread and
per-non-threaded-process CPU utilization levels by number of
cpus, so they can utilize the whole row.
|
|
Much of this stuff is pretty sloppy ever since it was first
written as a casual experiment. Fixup types to use
size_t/ssize_t where appropriate, and free the actual realloc'd
member of the char_array struct - the container struct with the
assumption that the member is at the struct start.
|
|
This upsets clang in particular, mechanical type substitution.
|
|
Mechnical fix of longstanding typo I'm tired of ignoring...
|
|
Exposed as VMON_SYS_STAT_BOOTTIME, so part of VMON_WANT_SYS_STAT,
in units of ticks to normalize with SYS_STAT_CPU* times.
This also introduces vmon->ticks_per_sec, which callers can access
as well for convenience since vmon_t is all public and this library
doesn't aspire to keep anything private. It's initialized via
sysconf(_SC_CLK_TCK) @ vmon_init().
|
|
We need to eventually plumb an vwm_overlays_t reference back to sample_cb,
for now we'll just obviate the need for the vwm_ptr global by plumbing the
vwm_t through.
|
|
Long overdue house cleaning.
The addition of compositing/monitoring overlays in vwm3 pushed vwm well past
what is a reasonable size for a simple thousand line file. This is a first
step towards restoring sanity in the code, but no behavioral differences are
intended, this is mostly just shuffling around and organizing code.
I expect some performance regressions initially, follow-on commits will make
more improvements to that end as the dust settles.
|
