On 02/18/15 01:03, Maxim Kuvyrkov wrote:
The way SCHED_GROUP_P instructions have been handled historically is
by combination of two artifacts: (1) removing all dependencies for
instructions inside SCHED_GROUP sequence but the one to next insn,
and (2) maintaining a fast track for SCHED_GROUP insns that ensures
that once the first SCHED_GROUP insn is issued, scheduler does
nothing but issuing the single dependent insn of the current one.
The "fast track" was actually implemented by just advancing the cycle
counter forward by an appropriate number of cycles of a SCHED_GROUP_P
insn got queued. So the next iteration of the loop, the SCHED_GROUP_P
is magically ready along with potentially other instructions that had
been queued prior to the SCHED_GROUP_P insn.
But that was OK (of course) because the SCHED_GROUP_P insns get priority
over everything else that is ready on a particular cycle.
Bernd's work broke because the SCHED_GROUP_P insn got queued, but the
cycle counter only moved forward one tick. Thus previously queued insns
could become ready while the SCHED_GROUP_P insn was waiting.
My fix restores correctness by queuing the SCHED_GROUP_P insn for just a
single cycle (it may get queued again, but that's OK as everything else
that's ready in the same cycle as a queued SCHED_GROUP_P insn will get
re-queued as well). It's marginally less compile-time efficient, but it
was an easy, clean fix.
jeff
