| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
openzfs_sysctl_init() now returns void instead of int.
The ZfsArcStats->enabled flag is set inside the init function
now, instead of having to be set from its return value.
Preparation for more flag setting in Compressed ARC commit.
ZfsArcMeter_readStats() added and all Meter->values[] setting
moved to it, eliminating duplicated code in
{darwin,freebsd,linux,solaris}/Platform.c.
|
| | |
|
| |
| |
| |
| |
| | |
Darwin and FreeBSD export zfs kstats through the
same APIs, so moving functions into a common file.
|
| | |
|
| |
| |
| |
| |
| |
| | |
If no pools are imported (ARC size == 0) or the
ZFS module is not in the kernel (/proc/spl/kstat/zfs/arcstats
does not exist), then the Meter reports "Unavailable".
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
New meter displays same ARC stats as FreeBSD top(1).
Can be extended to other platforms that support ZFS.
Pulling kstat.zfs.misc.arcstats.c_max as the meter
total, so the meter has a meaningful value to work
up to.
The Text meter displays, first, the maximum
ARC size (Meter.total), then second, the total
ARC used, using the difference between Meter.maxItems
and Meter.curItems to "hide" the used value from the
Bar and Graph drawing functions by using an index
in Meter.values[] that is beyond curItems - 1, but
less than maxItems - 1.
|
| |
| |
| |
| |
| | |
Could have resulted in a buffer overflow if the
FreeBSD kernel returned more bytes than expected.
|
|\ \ |
|
| | | |
|
| | | |
|
| |/ |
|
|\ \ |
|
| |/
| |
| |
| | |
This closes issue #930.
|
|\ \ |
|
| |/
| |
| |
| | |
If the user informed wrong value, then let them know about that.
|
|\ \ |
|
| |/ |
|
|\ \ |
|
| |/
| |
| |
| | |
The option should be informed to the linker.
|
|\ \ |
|
| | | |
|
| |/ |
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit adds a "vim_mode" setting (false/`0` by default) that causes
keys to be remapped in the following way by the `ScreenManager`:
+ h -> LEFT
+ j -> DOWN
+ k -> UP
+ l -> RIGHT
+ LEFT -> h (toggle help)
+ DOWN -> j (noop)
+ UP -> k (open kill menu)
+ RIGHT -> l (lsof current process)
+ K (Shift+K) -> k (open kill menu)
+ J (Shift+J) -> K (toggle show/hide kernel threads)
+ L (Shift+L) -> l (lsof current process)
I couldn't figure out where the manpage documentation is in the repo,
though I admittedly did not look particularly hard.
I believe this change would be a welcome option for heavy vim users like myself
who would like a familiar way to get around in htop.
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | | |
reason: currently, for example 'search' and 'filter' look very densely packed
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This way the frequency is read from sysfs only once per update cycle
instead of every time the UI is redrawn.
This also changes the code to read from /proc/cpuinfo instead. This is because
reading from scaling_cur_freq stalls for 10ms if the previous read for the file
was more than one second ago. [1] Since htop's update cycle is
longer than that, it would cause the read of each CPU's scaling_cur_freq file
to block the UI for 20ms. This easily led to a noticeable half-second lag on
a 20+ CPU machine.
/proc/cpuinfo also has a 10ms delay, but this applies for the whole file
so the delay does not scale with the number of CPUs. [2]
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4815d3c56d1e10449a44089a47544d9ba84fad0d
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7d5905dc14a87805a59f3c5bf70173aac2bb18f8
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The option is only implemented on Linux. On other platforms, and on Linuxes
that do not expose the relevant sysfs file, the frequency will be 0.
The "CPU average" meter does not show a frequency, only
the individual per-CPU meters.
|
|\ \ \ |
|
| | | | |
|
| |/ / |
|
|\ \ \ |
|
| |/ / |
|
|\ \ \ |
|
| |/ / |
|
|\ \ \ |
|
| |/ / |
|
|\ \ \ |
|
| | | | |
|
| | |/
| |/| |
|