It seems reasonable to put functionally-related software into the same scheduler partition, and frequently that's the right choice. However, adaptive partitioning thread scheduling is a structured way of deciding when not to run software. So the actual method is to separate the software into different scheduler partitions if it should be starved of CPU time under different circumstances.
For example, if the system is a packet router that:
it may seem reasonable to have two scheduler partitions: one for routing, and one for topology. Certainly logging routing metrics is functionally related to packet routing.
However, when the system is overloaded, meaning there's more outstanding work than the machine can possibly accomplish, you need to decide what work to do slowly. In this example, when the router is overloaded with incoming packets, it's still important to route them. But you may decide that if you can't do everything, you'd rather route packets than collect the routing metrics. By the same analysis, you might conclude that route-topology protocols should continue to run, using much less of the machine than routing itself, but run quickly when they need to.
Such an analysis leads to three partitions:
In this case, we chose to separate the functionally-related components of routing and logging the routing metrics because we prefer to starve just one if we're forced to starve something. Similarly, we chose to group two functionally-unrelated components, the logging of routing metrics and the logging of topology metrics, because we want to starve them under the same circumstances.