r353430 cem Oct. 11, 2019, 6:02 a.m.
cy@ points out that I got parameter order backwards between definition and
invocation of the helper function.  He is totally correct.  The earlier
version of this patch predated the XFree column so this is one I introduced,
rather than the original author.

Submitted by:	cy
Reported by:	cy
X-MFC-With:	r353429
r353429 cem Oct. 11, 2019, 1:31 a.m.
Add /i option for machine-parseable CSV output.  This allows ready copy/
pasting into more sophisticated tooling outside of DDB.

Add total zone size ("Memory Use") as a new column for UMA.

For both, sort the displayed list on size (print the largest zones/types
first).  This is handy for quickly diagnosing "where has my memory gone?" at
a high level.

Submitted by:	Emily Pettigrew <Emily.Pettigrew AT isilon.com> (earlier version)
Sponsored by:	Dell EMC Isilon
r353427 glebius Oct. 10, 2019, 11:55 p.m.
r353426 glebius Oct. 10, 2019, 11:54 p.m.
r353425 glebius Oct. 10, 2019, 11:51 p.m.
r353424 glebius Oct. 10, 2019, 11:50 p.m.
isn't needed here.
r353423 glebius Oct. 10, 2019, 11:49 p.m.
r353422 glebius Oct. 10, 2019, 11:48 p.m.
call to if_addr_rlock() isn't needed.
r353421 glebius Oct. 10, 2019, 11:47 p.m.
r353420 glebius Oct. 10, 2019, 11:44 p.m.
on interface.  Such function could been implemented on top of
the if_foreach_llm?addr(), but several drivers need counting,
so avoid copy-n-paste inside the drivers.
r353419 glebius Oct. 10, 2019, 11:42 p.m.
addresses.  The KPI doesn't reveal neither how addresses are stored,
how the access to them is synchronized, neither reveal struct ifaddr
and struct ifmaddr.

Reviewed by:	gallatin, erj, hselasky, philip, stevek
Differential Revision:	https://reviews.freebsd.org/D21943
r353417 cem Oct. 10, 2019, 10:49 p.m.
Refactor nvdimm_spa_memattr() routine and callers to just save the value at
initialization and use the value directly.  The reference value from NFIT,
MemoryMapping, is read only once, so the associated memattr could never

No functional change.

Sponsored by:	Dell EMC Isilon
r353416 dim Oct. 10, 2019, 8:33 p.m.
Fix process launch failure on FreeBSD after r365761

  enabled, launching any process on FreeBSD crashes lldb with:

  Expected<T> must be checked before access or destruction.
  Expected<T> value was in success state. (Note: Expected<T> values in
  success mode must still be checked prior to being destroyed).

  This is because `m_operation_thread` and `m_monitor_thread` were
  wrapped in `llvm::Expected<>`, but this requires the objects to be
  correctly initialized before accessing them.

  To fix the crashes, use `llvm::Optional<>` for the members (as
  indicated by labath), and use local variables to store the return
  values of `LaunchThread` and `StartMonitoringChildProcess`.  Then,
  only assign to the member variables after checking if the return
  values indicated success.

  Reviewers: devnexen, emaste, MaskRay, mgorny

  Reviewed By: devnexen

  Subscribers: jfb, labath, krytarowski, lldb-commits

  Differential Revision: https://reviews.llvm.org/D68723

PR:		241137
MFC after:	1 month
X-MFC-With:	r353358
r353415 dim Oct. 10, 2019, 8:30 p.m.
Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.

PR:		241137
MFC after:	1 month
X-MFC-With:	r353358
r353413 kib Oct. 10, 2019, 6:52 p.m.
Sponsored by:	The FreeBSD Foundation
MFC after:	3 days