On Wed, May 18, 2016 at 09:41:20AM +0100, Matt Fleming wrote:
> On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote:
> > On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> > > So, if the code looks like the following, either now or in the future,
> > >
> > > static void __schedule(bool pre
On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote:
> On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> > So, if the code looks like the following, either now or in the future,
> >
> > static void __schedule(bool preempt)
> > {
> > ...
> > /* Clear RQCF_ACT_SKIP */
> > rq->cl
On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> So, if the code looks like the following, either now or in the future,
>
> static void __schedule(bool preempt)
> {
> ...
> /* Clear RQCF_ACT_SKIP */
> rq->clock_update_flags = 0;
> ...
> delta = rq_clock
On Tue, 17 May, at 04:11:09AM, Yuyang Du wrote:
> On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote:
> >
> > No because if someone calls rq_clock() immediately after __schedule(),
> > or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we
> > should trigger a warning since
On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote:
> > >
> > > - rq->clock_skip_update = 0;
> > > + /* Clear ACT, preserve everything else */
> > > + rq->clock_update_flags ^= RQCF_ACT_SKIP;
> >
> > The comment says "Clear ACT", but this is really xor, and I am not sure
> > this is ev
On Sun, 15 May, at 10:14:39AM, Yuyang Du wrote:
> Hi Matt,
>
> Thanks for Ccing me.
>
> I am indeed interested, because I recently encountered an rq clock
> issue, which is that the clock jumps about 200ms when I was
> experimenting the "flat util hierarchy" patches, which really annoyed
> me, an
Hi Matt,
Thanks for Ccing me.
I am indeed interested, because I recently encountered an rq clock
issue, which is that the clock jumps about 200ms when I was
experimenting the "flat util hierarchy" patches, which really annoyed
me, and I had to stop to figure out what is wrong (but haven't yet
fig
There's no diagnostic checks for figuring out when we've accidentally
missed update_rq_clock() calls. Let's add some by piggybacking on the
rq_*pin_lock() wrappers.
The idea behind the diagnostic checks is that upon pining rq lock the
rq clock should be updated, via update_rq_clock(), before anybo
8 matches
Mail list logo
