The following change greatly reduced the p99lat of Redis serviceSo above change wants to wake up the short task on its previous
from 150ms to 0.9ms, at exactly the same throughput (QPS).
@@ -5763,6 +5787,9 @@ wake_affine_weight(struct sched_domain *sd, struct
task_struct *p,
s64 this_eff_load, prev_eff_load;
unsigned long task_load;
+ if (is_short_task(p))
+ return nr_cpumask_bits;
+
CPU if I understand correctly.
this_eff_load = cpu_load(cpu_rq(this_cpu));I see. My original thought was to mitigate short task migration
if (sync) {
I know that 'short' tasks are not necessarily 'small' tasks, e.g.
sleeping duration is small or have large weights, but this works
really well for this case. This is partly because delivering data
is memory bandwidth intensive hence prefer cache hot cpus. And I
think this is also applicable to the general purposes: do NOT let
the short running tasks suffering from cache misses caused by
migration.
as much as possible. Either waking up the task on current CPU or previous
CPU should both achieve the goal in theory. Could you please describe
a little more about how Redis proxy server was tested? Was it tested
locally or using multiple machines? I asked this because for network
benchmarks, it might be better to wake the task close to the waker(maybe
the NIC interrupt) due to hot network buffer. Anyway I will test
your change slightly changed to see the impact, and also Redis. But it
would be even better if you could provide some simple test steps I can
try locally : )