Change locking vm_reserv_reclaim_inactive() following a suggestion
from Jeff: instead of using the scan lock, take the domain lock
and reclaim from the first reservation where trylock succeeds.
Drop the domain lock as soon as the reservation as dequeued. This
way we avoid holding any domain-global reservation locks while the
reservation is being broken.

Hopefully address all of the feedback.

In D22396#489880, @dougm wrote:

I can't comment on the accuracy of any of this, but I can channel my 9th grade English teacher, Mrs. Weaver. There's some more passive voice in there (is awakened? by who?), but you're probably more interested in technical feedback.

Seems ok to me.

Handle Alan's notes.

In D22394#490201, @jeff wrote:

We run all of our paging threads constantly now. I would prefer not to disable creating cache buckets from pageproc unless we're in low memory situation. Even then it may be preferable to simply flush the buckets at the end of paging in that case.

This was committed as r352688.

In D22392#490198, @jeff wrote:

I don't see the lock leak? again or continue both expect the lock held.

Address feedback.

Address feedback.

It would be nice if the loop variable names were more consistent: in some places we use prev_entry/entry, in others it's temp_entry/current or entry/current, etc.. I think I prefer prev_entry/entry, FWIW. Anyway, that does not block this patch.

Thanks. If you plan to commit this patch on its own, I'd suggest adding a comment above defer_next, even though that definition would be deleted shortly after.

In D20722#488436, @rlibby wrote:

In D20722#488420, @markj wrote:

Ryan, are you planning to commit this at some point?

Sorry, got busy for a bit. Yes, let me make sure test and make sure it is still current, and then I'll try to get it in by this weekend.

Ryan, are you planning to commit this at some point?

I read through this a couple of times and it seems fine to me. You might consider breaking this into several patches, the first of which introduces vm_map_entry_{pred,succ}() as wrappers for direct accesses of entry->next and entry->pred and converts existing code to use them.

Count contiguous l3 ranges.

In D22261#487620, @pho wrote:

I completed a full stress2 test with D22261.64008.diff.
The only problem I saw was this (unrelated) panic: https://people.freebsd.org/~pho/stress/log/mark107.txt

I'd find the name VPB_CURTHREAD_EXCLUSIVE more intuitive.

Why don't we just have a "name" parameter that determines the entire gnop provider name?

In D21875#478792, @graeme.jenkinson_cl.cam.ac.uk wrote:

In D21875#478050, @markj wrote:

In D21875#477890, @graeme.jenkinson_cl.cam.ac.uk wrote:

In D21875#477846, @markj wrote:

This makes sense to me, thanks. I'll commit it in a day or two if no one else jumps in.

Cool. It's only a minor thing but we are increasingly relying on correct knowledge of the internals of DIF and DOF to do our work on distribution.

Is there a "Sponsored by:" tag you'd like added to the commit message?

I'll just double check with Robert, I've just got a letter about contract extension. I think this is funded differently. Robert says DARPA/AFRL ATM, so some/all of the following blurb?
This software was developed by BAE Systems, the University of Cambridge Computer Laboratory, and Memorial University under DARPA/AFRL contract FA8650-15-C-7558 ("CADETS"), as part of the DARPA Transparent Computing (TC) research program.
Let me know if I should be putting this somewhere I couldn't see a way I can add this.

In D22141#487424, @andrew wrote:

Can you commit this or shall I commit D22241 first? They conflict as they both change pmap_qenter() and pmap_kenter().

I spent some more time looking at this today. This change can't be committed:

• pmclog_close() logs an EOF message causes the logging thread to flush all pending buffers and exit. pmclog_close() returns without waiting for the flush to complete: this is necessary because the logging thread might be writing to a pipe, and we need the calling thread to go back and read from it. But, clearing PMC_PO_OWNS_LOGFILE without waiting may cause the logging thread to exit before it logs EOF, and this breaks some existing applications.
• pmclog_close() doesn't fdrop() the log file reference, so by clearing PMC_PO_OWNS_LOGFILE the change allows unprivileged users to trigger a refcount leak.