FYI - Some details on how this works on Mac and Linux from what I could find in the .NET Core source.

The PriorityClass setter calls the PriorityClassCore setter, which has the following comment/values:

// This mapping is relatively arbitrary.  0 is normal based on the man page,
// and the other values above and below are simply distributed evenly.

int pri = 0; // Normal
switch (value)
{
    case ProcessPriorityClass.RealTime: pri = -19; break;
    case ProcessPriorityClass.High: pri = -11; break;
    case ProcessPriorityClass.AboveNormal: pri = -6; break;
    case ProcessPriorityClass.BelowNormal: pri = 10; break;
    case ProcessPriorityClass.Idle: pri = 19; break;
    default:
        Debug.Assert(value == ProcessPriorityClass.Normal, "Input should have been validated by caller");
        break;
}

int result = Interop.Sys.SetPriority(Interop.Sys.PriorityWhich.PRIO_PROCESS, _processId, pri);

And Interop.Sys.SetPriority ends up calling setpriority

If anyone has ideas of how to test this, I'm open to suggestions.

For my manual test, I loaded Task Manager, went to the "Details" page, and added the "Base priority" column. Then, I ran the PackfileMaintenanceStep using the gvfs dehydrate command. I watched git.exe pop up with "Below Normal" priority.

my manual test, I loaded Task Manager, went to the "Details" page, and added the "Base priority" column. Then, I ran the PackfileMaintenanceStep using the gvfs dehydrate command. I watched git.exe pop up with "Below Normal" priority.

Do you have an idea of how much longer the job takes with "Below Normal" priority? It would be a good to test running some meaty things on the machine and try it with/without the priority change.

I can't think of a great automated test. I imagine we could run a background job on a functional test and verify it was set up with "Below Normal" priority, but I don't think that would be worth it. I'd be more interested in knowing the impact of changing the priority.

Do you have an idea of how much longer the job takes with "Below Normal" priority? It would be a good to test running some meaty things on the machine and try it with/without the priority change.

The tricky part here is that if the computer is not in use, then it shouldn't take any longer, right? But if someone is running a build, then the step will now take a lot longer than before. It won't use any resources while it is being skipped in favor of other processes, so these longer times shouldn't have user-facing effects.

The tricky part here is that if the computer is not in use, then it shouldn't take any longer, right? But if someone is running a build, then the step will now take a lot longer than before. It won't use any resources while it is being skipped in favor of other processes, so these longer times shouldn't have user-facing effects.

I agree. In the past we've been concerned about long running background jobs. Should we continue to be concerned with this or accept we are going to get some slow runs by design (and they aren't hurting anything because of the priority drop)?

I think its worth doing the simple test you describe locally where you run a build while maintence is running as a data point.

Should we continue to be concerned with this or accept we are going to get some slow runs by design (and they aren't hurting anything because of the priority drop)?

Things running slower in the background is not only acceptable, but desirable. There's no rush to fix something that's been a problem for weeks or months. We can do it a few seconds slower and not irritate users.

👍 I like marking the background tasks to run at a lower priority. At least it conveys our intention of how we want the process to run.

I'm only advocating we test it once manually, during a build (or another busy time) before shipping - and report the results as a benchmark. I definitely think we should take the change.

I have run this locally, and watched the processes start with lower priority. Measuring the end-to-end time change is unlikely to have conclusive evidence, because (1) these commands already have high variance between runs, and (2) it will change depending on the load we are putting on the machine.