Messages in this thread | | | Date | Fri, 6 Oct 2023 12:35:19 -0400 | From | Daniel Jordan <> | Subject | Re: [PATCH] sched/fair: Preserve PLACE_DEADLINE_INITIAL deadline |
| |
Hi Prateek,
On Thu, Oct 05, 2023 at 11:26:07AM +0530, K Prateek Nayak wrote: > Hello Daniel, > > On 10/4/2023 6:47 AM, Daniel Jordan wrote: > > An entity is supposed to get an earlier deadline with > > PLACE_DEADLINE_INITIAL when it's forked, but the deadline gets > > overwritten soon after in enqueue_entity() the first time a forked > > entity is woken so that PLACE_DEADLINE_INITIAL is effectively a no-op. > > > > Placing in task_fork_fair() seems unnecessary since none of the values > > that get set (slice, vruntime, deadline) are used before they're set > > again at enqueue time, so get rid of that and just pass ENQUEUE_INITIAL > > to enqueue_entity() via wake_up_new_task(). > > > > Fixes: e8f331bcc270 ("sched/smp: Use lag to simplify cross-runqueue placement") > > Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> > > I got a chance to this this on a 3rd Generation EPYC system. I don't > see anything out of the ordinary except for a small regression on > hackbench. I'll leave the full result below.
Thanks for testing!
> o System details > > - 3rd Generation EPYC System > - 2 sockets each with 64C/128T > - NPS1 (Each socket is a NUMA node) > - Boost enabled, C2 Disabled (POLL and MWAIT based C1 remained enabled) > > > o Kernel Details > > - tip: tip:sched/core at commit d4d6596b4386 ("sched/headers: Remove > duplicate header inclusions") > > - place-deadline-fix: tip + this patch > > > o Benchmark Results > > ================================================================== > Test : hackbench > Units : Normalized time in seconds > Interpretation: Lower is better > Statistic : AMean > ================================================================== > Case: tip[pct imp](CV) place-deadline-fix[pct imp](CV) > 1-groups 1.00 [ -0.00]( 2.58) 1.04 [ -3.63]( 3.14) > 2-groups 1.00 [ -0.00]( 1.87) 1.03 [ -2.98]( 1.85) > 4-groups 1.00 [ -0.00]( 1.63) 1.02 [ -2.35]( 1.59) > 8-groups 1.00 [ -0.00]( 1.38) 1.03 [ -2.92]( 1.20) > 16-groups 1.00 [ -0.00]( 2.67) 1.02 [ -1.61]( 2.08)
Huh, numbers do seem a bit outside the noise. Doesn't hackbench only fork at the beginning? I glanced at perf messaging source just now, but not sure if you use that version. Anyway, I wouldn't expect this patch to have much of an effect in that case.
| |