BORE: Restore default base slice value of 2ms

[1Naim]

Currently, we set the min_base_slice_ns value of BORE to 1000000 (1ms). This was previously added to circumvent some audio crackling and glitches
using 1000Hz kernel. However, a few benchmarks I did (see below) shows that throughput is worse with a base slice of 1ms compared to 2ms.
This behaviour is expected and it doesn't matter much when using BORE as a scheduler because we are not focused on throughput, but rather deskop responsiveness
and interactivity. What was unforeseen however, was the fact that responsiveness under heavy load was also hurt by lowering the base slice to 1ms.

@firelzrd, the developer of BORE, has also stated that a base slice of anything lower than 2ms will cause excessive scheduling, poor cache efficiency and
increased CPU overhead. It will also lower throughput (as mentioned earlier) which can also harm responsiveness.

Users can compare between these two base slice values by the following command for testing:

echo 2000000 | sudo tee /sys/kernel/debug/sched/min_base_slice_ns

[ptr1337]

The problem was, that setting the default value together with 1000 Hz introduced audio stutters

[1Naim]

The problem was, that setting the default value together with 1000 Hz introduced audio stutters

Ironically, I get more audio crackles with 1ms than 2ms. Also, the reportee who got the audio stutters was using an absurdly low minimum quant of 32. Setting the base slice to 1ms at runtime also didn't fix it for them which is weird to me.

absurdly low minimum quant of 32

To clarify this, there is nothing wrong with the minimum value in of itself. Problems arise when apps are patched to use the min quant or forcing the min quant for an app instead that makes use of this value and in turn causes crackles if the sound card/CPU isn't able to handle it.