Improve functions' documentation of their busy argument based on Keith's explanation from Slack:

The busy argument indicates that eviction should only be performed if eviction is mandatory. I.e., if the cache is over any of the eviction triggers.

Looking at that function, the first use of busy is early in the function:
 

    if (!__wt_atomic_loadbool(&conn->evict_server_running) || (busy && pct_full < 100.0))
        goto done;

This condition is skipping past the body of the function – the part that does eviction – if the busy is set and if we are below the eviction targets. pct_full is calculated such that it will be >= 100.0 if any the cache is above any of the triggers.

Hence my statement that busy indicates that "eviction should only be performed if eviction is mandatory" because the cache is over at least one trigger.

(Note that if we make it past this check, busy is also used to limit how much eviction work the function does, and to determine which stats get updated.)

But as Sid points out, that doesn't make sense since we define the trigger parameters as the threshold where application threads perform eviction (e.g., eviction_dirty_trigger). So what is that check doing?

__wti_evict_app_assist_worker is called in exactly one place. Here's an abridged version of that code:
 

    if (!__wt_evict_needed(session, busy, readonly, &pct_full))
        return (0);

     . . .

    return (__wti_evict_app_assist_worker(session, busy, readonly, pct_full));

__wt_evict_needed returns true if the cache exceeds at least one trigger, and we only call __wti_evict_app_assist_worker if that is the case.

So it appears that the pct_full < 100.0 check in __wti_evict_app_assist_worker will always be true and could probably be removed.

Going back a bit earlier, the busy flag is set in two circumstances:

• We are in the process of reading a page into the cache (here and here)
• The thread holds resources (active transaction, hazard pointers, etc) that might block other threads from making progress

These are circumstances where using the application thread for eviction is going to directly impact the performance of WT operations.

If busy is set, we also ignore the dirty trigger for the purpose of determining whether eviction is needed. (Given the logic here, I wonder if we should also ignore the update trigger when busy is set. Clean eviction is much less work than dirty/update eviction, since it doesn't need to reconcile and write the page).

Putting it all together, I would say that the busy flag is used to minimize the eviction work an application thread does in cases where other operations might be waiting on resources the thread holds.

If it makes the code easier to understand, think of a better name for that argument.