I've seen much conflicting information about what choice to make regarding the Processor Scheduling option under Advanced System Properties \ Advanced Performance Options \ Processor Scheduling on a Windows Server.  I wanted to get to the bottom of this for a dedicated SQL Server.  Having spent 10 + years as a Manager/Senior Production DBA in high OLTP environments (Monster.com, VistaPrint.com, etc.), I figured I could wade through the large volume of forums/blogs/articles and decipher the frequently ambiguous and sometimes incorrect information.  What I typically found was conflicting information based on simplistic approaches and a lack of understanding of exactly what these memory options actually do.  Choosing this memory option is important and shouldn't be made based on whether you run "applications" or "services"...of which people disagree about which there program even is.  

First, here's some background on the components involved in determining the correct choice for Processor Scheduling.   

1) The Windows Scheduler The Windows scheduler is a preemptive scheduler that prevents a single thread from monopolizing a processor/server.  Each Windows thread gets a specified time slice in which to run, after which Windows automatically schedules it off the processor and allows another thread to run if one is ready to do so.   

Regarding whether one should choose Application versus Background Services, we first need to understand what they mean.  The Windows Scheduler uses time units called "Quantums" to slice time into pieces that it allows threads to occupy a processor and perform work.  Once a thread completes its allowed quantums (slice of time) on a processor, Windows switches that thread off the processor and allows another thread to perform work for the allowed quantums; this thread change is called a "context switch".  context switching prevents a CPU-bound process from monopolizing the processor(s).  Currently in Windows, 3 quantums are equal to either 10 milliseconds (single processor) or 15 milliseconds (multiple-processor Pentium).  

Time slices are fixed at 36 quantums (approximately 180 ms) on multi-processor servers when "Background Services" is selected (this applies to both foreground applications and background processes).  The time slice drops to 120 ms on single-processor boxes.  When "Programs" is selected, quantums are no longer fixed at 36, but vary depending on the thread type.  Background tasks receive 3 quantums (10-15 ms) and foreground tasks (applications) receive 9 quantums (30-45 ms).  So we see how the "Applications" choice actually takes effect...forground applications get 3X the time slice each time they are switched into an active state on a processor.  

When we choose "Background Services", 36 quantums of time are given whether the thread is foreground or background.  Windows takes this approach for "Background Services" because background processes are assumed to have fewer threads than applications and would be more efficient with more CPU time between context switches.  Interactive programs are assumed to be more efficient (and appear more responsive) with shorter time slices because they are assumed to use more active threads.  This allows them to respond more quickly to things (like keyboard input and mouse movement).  

So...which one is better for SQL Server?  Well...if you have a dedicated SQL Server box (no user applications running)...it matters only a little.  Let's talk about a cool little thing called the SQL Server User Mode Scheduler (UMS in SQL 7/2000, SQL OS [SOS] in SQL 2005).  

2) User Mode Scheduler(UMS/SOS) UMS/SOS sits between the SQL Server and the operating system.  Its primary function is to keep as much of the scheduling process as possible in control by SQL Server.  When SQL Server starts, one UMS scheduler is created for each processor in the machine.  

We learned that the windows scheduler is preemptive and context switches occur based on time.  The SQL Scheduler uses "cooperative" scheduling which means it relies on threads to yield voluntarily.  This prevents context switching by allowing threads to complete work before getting switched off a processor automatically based on time slices.  Why does this perform better and scale better than using the Windows Scheduler?  Because SQL Server knows its own scheduling needs better than Windows.  

You might be wondering how the SQL UMS/SOS keeps the Windows Scheduler from context switching all the UMS/SOS controlled SQL threads?  It does this by tricking the windows scheduler into ignoring all but 1 thread at a time from the many threads connected to the processors from SQL's UMS/SOS.  Each UMS/SOS thread has an associated event object and Windows Scheduler ignores any with the type "WaitForSingleObject" with a timeout of "INFINITE".  UMS/SOS keeps all but 1 thread in this state per processor so only 1 thread is active on a processor at any given time...allowing the thread to complete its work without being context-switched off the processor by windows scheduler.  

So, while the Windows Scheduler is switching active threads on and off each processor, SQL UMS/SOS is deciding which 1 SQL thread is getting processed.  This keeps the number of SQL threads available for context switching on a processor to 1.  It is true that Windows still needs to context switch other non-SQL internal/background threads on and off...so active SQL threads don't get 100% of the CPU time and are still subject to context switching.  However, there should be relatively few other active background threads on a dedicated SQL Server compared to an Application server.  Also, choosing background services for the advanced memory parameter will keep those SQL threads processing in longer (36 quantum) time slices versus getting context switched at 3 quantums.   So, with no foreground applications running, and in the "Application" scheduler mode, SQL threads will context switch more frequently when other background processes are active.  With no foreground applications running, and in the "Background Services" mode, SQL threads will context switch less when other background services are active.  In either scenario SQL threads receive the same processing time, but experience different frequencies of context switching.  Context switching utilizes system resources and, therefore, should be reduced if at all possible.  Choosing "Background Services" on a dedicated SQL Server makes sense even if there are not many other background processes running; it reduces context switching and, therefore, increases available system resources for SQL Server.