| Age | Commit message (Collapse) | Author |
|---|
|
Mechanical renaming of this vestigial name choice from when
vmon_proc_t was below the "monitor". Now it's just the
vmon_proc_t pointed at from the chart, so let's name accordingly.
No functional change.
|
|
More clarification of delay/timeout units in naming.
|
|
More clarification of delay/timeout units in naming
|
|
This API is targeting poll() usage which implies microseconds,
but let's better clarify it in naming.
|
|
vcr_backend_poll() mirrors the poll() api, but let's clarify the
timeout units as microseconds.
|
|
For rows reflecting threads and single/non-threaded processes,
let's scale the bar % by the number of cpus, so they can use the
full height of the row.
These tasks can't scale to multiple CPUs, so it's pointless to
leave vertical space for the other cores' capacity, if present.
For multi-threaded process rows, the vertical space continues to
accomodate all cores.
I've been on the fence about this change for a while because it
increases the cognitive load of reading the graphs, now the
scales are inconsistent. But when you've got 16 cores like on my
AMD P14s thinkpad, combined with a row height of 16 pixels, you
start wishing these rows used the full height of the row for
their single-core-constrained %ages.
|
|
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.
|
|
I planned to use the 256-colors for differentiating graphs in
other row types, but it's becoming clear saving space is more
important.
So this cuts the file size down further quite a bit:
-rw-r--r-- 1 vc vc 219323 Sep 19 01:37 09.19.24-01:36:43-2.png
Becomes:
-rw-r--r-- 1 vc vc 152674 Sep 21 14:25 09.21.24-14:25:16-2.png
|
|
This introduces a LUT indirection table for mapping the raw layer
values to a dense, deduplicated palette used with the PNG.
This should help with compression ratios at basically no cost.
Before `1800x8000 --headless --snapshot 10 --hertz 60`:
-rw-r--r-- 1 vc vc 87873 Sep 19 01:36 09.19.24-01:36:43-0.png
-rw-r--r-- 1 vc vc 215719 Sep 19 01:36 09.19.24-01:36:43-1.png
-rw-r--r-- 1 vc vc 219323 Sep 19 01:37 09.19.24-01:36:43-2.png
-rw-r--r-- 1 vc vc 221979 Sep 19 01:37 09.19.24-01:36:43-3.png
After:
-rw-r--r-- 1 vc vc 72303 Sep 19 01:37 09.19.24-01:37:30-0.png
-rw-r--r-- 1 vc vc 174100 Sep 19 01:37 09.19.24-01:37:30-1.png
-rw-r--r-- 1 vc vc 177430 Sep 19 01:37 09.19.24-01:37:30-2.png
-rw-r--r-- 1 vc vc 178711 Sep 19 01:38 09.19.24-01:37:30-3.png
Without any increase in compression level used. Which while it
would improve ratios further, substantially increases CPU cost.
|
|
This reverts commit 9f564cf8df6ef5fcba37082ba8013d6175955125.
Experimenting with smaller initial seq_file buffers in the kernel
has exposed this actually breaks, which contradicts my
expectations for proc files established back in the /proc/mdstat
racy incremental parsing corrupting the output days.
I'm seeing /proc/$pid/task/$pid/children spit out short reads
when the seq_file size is smaller than the amount of output.
Userspace's read() call can provide a large buffer, and if
seq_file's is smaller than the children output, it'll split the
children output instead of enlarging the seq_file buf to the
read() buffers bounds.
|
|
It'd be nice to allow the last partial row to be rendered, but
as-is it can result in segfault for some operations that aren't
clipping at that granularity.
Another option is to always round up the bits allocation to the
ROW_HEIGHT boundaries, then not worry about this, and do the
partial clip @ serialization to png time.
|
|
Increasing contrast a bit for odd rows / separators
|
|
This should have been changed when transitioning to nibbles and
the separators became generated @ present time when serializing
to png.
The first pass clears the shadow layer while assigning the first
offset part of the shadow. But it was staying within the
separators, which is now resulting in small bits of littered
shadow corruption in the separators barely visible in the PNGs.
Fix is trivial; initialize the separator bits when shadowing the
row as well.
|
|
Eventually this should get applied semi consistently to all
snapshots, but I'm most annoyed by its omission from the
--headless PNGs at the moment.
Also it arguably makes sense to always start with extending the
constrained mem-to-png case where we're working with a 256-color
palette, since the Xlib/XRender case has effectively no
constraints. Or just abandon any hope of preserving consistency
across the rendered output modes..
|
|
There's still assumptions that everything in the hierarchy fits
within the canvas... the Xlib stuff would clip all this behind
the scenes, but vcr/headless mode doesn't have such guard rails.
At some point I need to sit down and do a thorough pass in this
vein... Fortunately most my headless use cases have the canvas
configured appropriately.
|
|
When using vmon to monitor a system PID1 will kill it @
shutdown/reboot, and we should save one last snapshot of what's
been captured before we exit in that case.
SIGTERM is sent first before the SIGKILL killing spree, so let's
handle the SIGTERM by writing the snapshot, then exiting the main
loop.
The service manager can then do something with the produced
snapshots after we've exited, if they're considered interesting.
|
|
8 layers is no longer supported as a future expansion path...
|
|
These snuck in during the Xlib->vcr refactor which involved a lot
of copy-n-pasta taking Xlib sections from charts.c
|
|
This mostly works, but the maintenance of text shadows are a
gross naive conversion of the pre-nibbles code. It would
probably be better to add the shadows @ mem->png serialization
time and not bother maintaining them at all for headless.
It seems to work well enough to exercise and evaluate memory
footprints though...
The reason for "nibbles" is to save memory. Prior to this, the
mem backend would use a byte per pixel of layer information. By
not storing the background layer in this space, the current set
of layers used can fit in 4 bits (aka a nibble).
So this commit pivots to packing two pixels worth of layer data
into each of those bytes, effectively cutting the memory
requirements of the mem backend (headless mode) in half.
It matters for embedded use cases. The next step from here to
use substantially less memory in headless mode would require a
deeper refactor where we don't maintain a bitmap style
representation at all. It's doable, but not in the cards for my
free time right now.
|
|
--wip-name sets a constant name to use for the pre-rename temp
name of snapshots.
Otherwise a dynamic dot-filename augmented from the destination
name is used.
The impetus for this is to simplify garbage collection of
produced PNGs. We'll ignore dot-files to never step on the WIP
file during GC, but would like vmon to truncate and reuse the
same WIP name so it's not potentially accumulating the dot-files
in weird failure modes where the snapshots repeatedly fail to
complete and get renamed.
So in such a scenario we'll pass a dot-file for --wip-name and
vmon will keep reusing that name, never leaking more than the
single WIP file in even a persistent a failure mode.
|
|
cosmetic change; insert a space after the "#" in the string used
when comm/argv can't be sampled
|
|
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 switches to constructing the WIP png in a temporary dot-file
derived from the final name, then an atomic rename from the
dot-file to the final name. The temporary name is placed in the
same directory as the final one.
|
|
|
|
This upsets clang in particular, mechanical type substitution.
|
|
proc->stores is always allocated as part of vmon_proc_t, so this
can't possibly be NULL. IIRC an earlier form of libvmon
allocated the stores array lazily once needed.
|
|
There's no children processes expected for threads, and the
sampler assumes this is the case - but let's assert it holds
true.
|
|
Clarify the naming here so it's more obvious this only applies to
the single-pass mode (!VMON_FLAG_2PASS && !VMON_FLAG_PROC_ARRAY).
|
|
libvmon's internal api for samplers is extremely ad-hoc and
implicit.
This was done at the time to keep the source compact and have the
sampler ctor/dtor branches commingled immediately adjacent to
eachother... the thinking being this would help keep them in sync
as the code evolved. The ctor branches generally open fds and
allocate resources, with the dtor intended to undo those things.
With them kept more or less in the same page of code, it /should/
be obvious when one changes the other must as well.
In the long-term it probably makes sense to just explode this api
to something more formal and step back from those assumptions.
In lieu of doing such a refactor, let's improve the situation by
asserting the return codes at least stay within the expected
range. i.e. let's abort when a sample_changed/unchanged/error
return code comes from an dtor invocation, since this implies a
program error where someone isn't handling the implicit dtor
branches properly, instead falling through sampling paths.
|
|
Mechnical fix of longstanding typo I'm tired of ignoring...
|
|
Funny how long one can ignore something like this in their window
manager when X resources are in play, plus having 16G RAM helps.
|
|
It's actually pretty useful to see the relative PID values
across snowflakes...
|
|
Part of the reason for adding headless support in vmon is to
facilitate embedded use cases. These are often incompatible with
anti-tivoization aspects of gplv3.
I am the copyright holder of all this stuff so it's entirely fine
to switch to gplv2. Phil Freeman contributed one trivial patch
(4183fbd), regardless I checked if he had any objections to the
gplv2 switch and he had none.
So here we go, gplv2 all the things.
|
|
|
|
This avoids a bunch of pread() returning 0 EOF-finding calls.
These are proc files, and actually shouldn't be getting read in a
loop like this at all because it's racy to do so. With proc
files you need to atomically read everything you wish to parse as
one sample as an atomic unit.
So this needs to be properly reworked to enlarge the buffer when
a read exhausts it, throwing away what was read, then repeating
the sample with the enlarged buffer.
But this is tenable for now until I get around to the proper
rework... just looking to reduce some sampling overheads on lower
end embedded devices.
|
|
This causes snapshot filenames to always get the current time
instead of the start time of the vmon session
|
|
Takes a number of seconds interval argument, arranges for an
interval timer to trigger the sigusr1 handler which causes a
snapshot to be generated.
e.g. `./vmon --snapshots 1` will produce a .png per second
|
|
|
|
This isn't currently very discoverable, and without mention of it
one is likely to just try sending SIGCHLD to vmon for snapshots.
|
|
I don't use these, this isn't really the way vwm is intended to
be used.
For launching higher-order applications that don't need special
wm integrations like recordMyDesktop, or just aren't launched
numerous times daily (like xterm, or xlock), the user is expected
to just use the "console" screen session's available shell to do
things like `firefox &` or `gimp &`... these things aren't
generally started hundreds or thousands of times per day like say
xterm where the launcher shortcut pays clear dividends.
xterm itself in vwm is also used as a sort of throwaway launcher
window. Since everything is kept in MRU order it really doesn't
matter that you've got tons of xterms littering the environment
in contexts/virtual-desktops you just never visit after using
them to launch the thing you are using.
|
|
This requires a current recordMyDesktop build supporting
--need-shortcuts which was just added for this use case.
You can omit --need-shortcuts to support older rmd versions, but
this is leaning on --need-shortcuts to prevent multiple rmd
instances from accidentally being executed concurrently. Also
the shortcuts are expected to be how one pauses/stops the
capture, no vwm-level integration has been added to signal the
process for this purpose.
The default shortcut in rmd for stopping is ctrl+mod1+s which
doesn't collide with vwm's grabs, so everything Just Works.
You can utilize the vwm process monitors as a convenient way to
observe rmd's status in terms of encoding after stopping a
capture. You can see the reduced Idle %age in the top row during
the encode, it'll go back to normal when completed. Or you can
focus the vwm console (the attached screen session) and actually
observe the rmd output to watch the encoding progress - one of
the advantages of vwm's console. Furthermore, you can also
observe the CPU use of recordMyDesktop in that window with the
monitors active.
The key bindings as of now are:
Mod1+Backspace: record the focused window (root window if there
are no windows / empty desktop is focused)
Mod1+Delete: record the whole desktop / root window, even if
there are windows focused, unlike Backspace which will capture
just the focused window if there are windows.
As-is this doesn't specify --full-shots, so it's always in
damage-tracking mode, which might not work well with OpenGL style
captures. There needs to be a way to specify variants in
launchers.def with modifiers, then there could be a +Shift
variant for these where --full-shots is added, or something.
Ideally there should be a pop-up dialog where you get an
opportunity to manipulate the flags passed on from a set of
options, but I'm not doing that right now. That way we could
toggle stuff like sound/no-sound, tweak the FPS rate, toggle
full-shots/damage-tracking, sound/video quality, etc. Maybe it's
best to just use an rmd front-end for that, but it feels like
it'd be nice for vwm to just have a generic little dialog
mechanism for launchers, then launchers.def could describe the
parameterized args for the dialog to present controls for.
^^ TODO
|
|
This borrows from vmon.c to support argument interpolation.
The only interpolation supported right now is %W for a hex
windowid of the focused window.
When no window is focused, the id of the root window is supplied.
This is a preparatory commit for rmd integration
|
|
There needs to be a bunch of this throughout the codebase, but
just doing this spot fix to silence warnings introduced by
subsequent commits... preparatory commit for rmd integration
|
|
|
|
It doesn't look like the /bin/sh -c style invocation is going
away anytime soon, so let's just rely on the PATH searching and
this becomes more tolerant of stuff being in /usr vs. /usr/local
etc. (preparatory commit for rmd integration)
|
|
Now you can explicitly set 0Hz for the monitoring, instead of
hitting a pile of Mod1+Left to get there. Leaving the blind
hammering on Mod1+Left to just lower the frequency to 1Hz rather
than disabling it.
|
|
It's nice to be able to blindly hit Mod1+Left a bunch to minimize
the monitoring overhead, like when trying to preserve battery
etc. But I've found myself sometimes annoyed that I've
completely disabled the monitors when I reach for the overlays.
This change removes the 0Hz option from the preset intervals, so
now when you lower monitoring by blindly hitting Mod1+Left a
bunch it'll bottom out at 1HZ.
A subsequent commit will wire up disabling the monitors to an
explicit vwm key combo (probably Mod1+z).
|
