on check_preempt_tick() function,
normally, "sysctl_sched_min_granularity" can guarantee the minimal execution slice (lower limit) for each tasks before preemption.

but i think, on __sched_period(), if nr_running exceed the nr_latency then "cfs_rq" slice will be "sysctl_sched_min_granularity * nr_running".

And current "se" will be allocated the "timeslice(conceptual)" within "sysctl_sched_min_granularity * nr_running" by it's weight. & it will be "ideal_runtime" on "check_preempt_tick()".

on this condition, some se can have the "ideal_runtime" which is smaller than "sysctl_sched_min_granularity" by it's weight.

... omit ...
3377 delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
3378 if (delta_exec > ideal_runtime) {
3379 resched_curr(rq_of(cfs_rq));
3380 /*
3381 * The current task ran long enough, ensure it doesn't get
3382 * re-elected due to buddy favours.
3383 */
3384 clear_buddies(cfs_rq, curr);
3385 return;
3386 }
3388 /*
3389 * Ensure that a task that missed wakeup preemption by a
3390 * narrow margin doesn't have to wait for a full slice.
3391 * This also mitigates buddy induced latencies under load.
3392 */
3393 if (delta_exec < sysctl_sched_min_granularity)
3394 return;
... omit ...

So, i wonder that how "sysctl_sched_min_granularity" can guarantee the minimal execution slice, always??

I'd appreciate it If someone can help me to solve this curiosity.

Thank you.
Best Regards