imp: s/vm_offset_t/uintptr_t/

In D45750#1043538, @imp wrote:

why the crazy vm_offset_t instead of uintptr_t??

In D45751#1043496, @tuexen wrote:

Why is an uint64_t not good enough to hold a pointer? Aren't pointers 32-bit or 64-bit on all architectures FreeBSD supports?

In D45707#1042749, @markj wrote:

Given that the next 70 lines are mostly manually setting bits in the mask, I'd err on the side of entirely removing this initialization.

kib: s/inline/__inline/

In D45711#1042461, @imp wrote:

Is this used in .h file or .c files?

In D45694#1042256, @kib wrote:

Would you please show the gcc warning, to satisfy my curiosity?

Doug, fyi, I'm interested to look, but probably won't have time until the weekend.

In D45624#1041594, @markj wrote:

[I don't have a lot of stake in this code and my thoughts here aren't very nuanced.]

I have also though of a significantly less complex approach that also avoids the bufobj interlock.

Given that we're unlikely to see new consumers of lockmgr going forward, I wonder whether sleepgen would might someday be useful for avoiding the vnode interlock in some cases? If not, then this seems like a lot of machinery to deal with one lock, though the diff isn't too big.

A variant idea with a smaller API, but instead with a callback from under the sleepq lock. No more sleepgen, and the caller passes a pointer to the holder count to avoid defining a new lock type.
https://github.com/rlibby/freebsd/commits/lockmgr-condwait/

• a58e8116ba7d lockmgr: introduce LK_CONDWAIT
• 656a20928470 getblk: avoid bufobj interlock when waiting on buf lock

So the point here is to move us away from needing memq at all, correct? Taking this patch by itself, I am not seeing a performance benefit (different from your other recent uses of PCTRIE_RECLAIM_CALLBACK).

I checked for warnings, nothing new in subr_pctrie.c, subr_rangeset.c, or swap_pager.c. Good to go.

LGTM. Did you check that clang and gcc don't produce warnings? I don't think they should. I can try applying and checking this evening if you haven't already.

So, the previous pindex tracking was totally unnecessary, we always tear down the whole tree, correct? From what I can tell, it looks like swp_pager_meta_build maintains a SWAP_META_PAGES alignment invariant for the keys, so we should never have been hopping over another entry anyway.

Logic looks good.

kib (IIUC):

• reassignbuf, given fence and bo lock, don't need atomic_set_acq_int
• getblkx, given fence, don't need atomic_load_int

In D45571#1039766, @kib wrote:

IMO this is somewhat strange change in isolation. What is the action of your caller if GB_NOCREAT does not return a buffer?

I am asking this because if you consider the buffer cache autonomously, there is a big race there, since another thread might create the buffer right after we did not found it, and the answer we get is already outdated.

Taking advice on style and proper atomic conventions.

Style nits, otherwise LGTM.

I have some nitpicks, but the actual logic looks good to me.

asomers feedback:

• cleanup was broken since it runs in a different context
• prefer swap to malloc type md
• rename $md0

realized we may need to wait after the re-taste

markj feedback: fix style while here

markj feedback: clean up error paths

asomers: tap was a bad example, use atf

In D45518#1038713, @rlibby wrote:

They are not hooked up to the sys/Kyuafile. I wonder why.

In D45518#1038712, @rlibby wrote:

In D45518#1038621, @markj wrote:

I don't know this GEOM well enough to say whether this is right, but I can't see any reason it's wrong. It's unfortunate that there are no regression tests for this code.

I see there are tests for other geoms in tests/sys/geom, but I haven't figured out how to run them yet. Do you know? I might be able to cobble together something basic at least.

In D45518#1038621, @markj wrote:

I don't know this GEOM well enough to say whether this is right, but I can't see any reason it's wrong. It's unfortunate that there are no regression tests for this code.

In D45510#1038444, @rlibby wrote:

In D45510#1038439, @dougm wrote:

I would expect an iterator to consist of an array of maxdepth pointers and a parent index and a leaf index. Initialization means setting the first array element to root and the counter to 1. Searching updates the path, and insert/remove operations can happen in constant time at the bottom of the path, given the leaf index, and iteration happens by incrementing the leaf index to the next non-null child or, if there is none, backing up the path as far as necessary to take a step further right.

Yes I think that would work, and probably has simpler logic. IIUC the maxdepth is about 16 or 21 levels (depending on arch, and I may be off by 1), so 128 or 84 bytes for the array. I guess that's not so bad.

In D45510#1038439, @dougm wrote:

In D45510#1038362, @rlibby wrote:

struct pctrie_iter {
struct pctrie_node *cur;/* current inner */
struct pctrie_node *prev;/* last inner, or ancestor, for peek_prev */
struct pctrie_node *parent;/* current parent, for remove and next */
uint64_t key; /* current position */
/* May need some state bits? */
};

It's not clear to me how the iterator could take two steps up the tree. You can use parent to get one step up, but how do you find the parent's parent? Only if every node stores it parent, I think, which would be a big change.