You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
distinguish file backend thread names across backend instances
A `FileBackend` spawns some number of threads to actually handle I/Os
once it's eventually attached to a device that supports block
operations. Those names were just `worker N`, though, and typically all
file backends were created with the same number of workers, so a running
Propolis would have `num-file-backend` threads named `worker 0`,
`worker 1`, etc. This made finding which threads you care about
somewhat more complicated than it needs to be.
Instead, include a block backend ID, and plumb that to file backends to
use in worker thread names. Now, for example:
```
$ pstack 28651 | grep 'worker 0'
------- thread# 21 / lwp# 21 [file backend 0/worker 0] -------
------- thread# 29 / lwp# 29 [file backend 1/worker 0] -------
------- thread# 45 / lwp# 45 [file backend 2/worker 0] -------
------- thread# 49 / lwp# 49 [file backend 3/worker 0] -------
------- thread# 53 / lwp# 53 [file backend 4/worker 0] -------
------- thread# 57 / lwp# 57 [file backend 5/worker 0] -------
------- thread# 61 / lwp# 61 [file backend 6/worker 0] -------
------- thread# 65 / lwp# 65 [file backend 7/worker 0] -------
------- thread# 69 / lwp# 69 [file backend 8/worker 0] -------
------- thread# 73 / lwp# 73 [file backend 9/worker 0] -------
------ thread# 77 / lwp# 77 [file backend 10/worker 0] -------
```
yippee! yay!
Having `type DeviceId = u32; type BackendId = u32` made me pretty
suspicious we (I) would accidentally pass one where I meant the other
and produce confusing probe output, so this comes with a new `define_id`
macro to newtype the ID and provide a bit of glue to make it useful.
This brings `hw::nvme::DeviceId` along for the change and gives a
hopefully-more-obvious home for what these IDs are, are not, and how
they relate - in particular, that while a VM consisting only of N NVMe
disks, today, will have NVMe controllers 0..N with block devices 0..N
and block backends 0..N, where each `i` is related to "the same thing",
this is not at all reliable. Today, one could flip an NVMe disk to
virtio-block and change NVMe->block mappings, while tomrorow we might
make devices concurrently and be totally nondeterministic!
0 commit comments