On Thu, Sep 22, 2016 at 11:39:09AM +0200, Peter Zijlstra wrote:
> bit banging the serial port is absolutely awesome, the rest of printk
> not so much.
I also have this second patch that goes on top of this.
I think I had more hacks (like using the per-cpu NMI buffers for output
instead of the
On Thu, Sep 22, 2016 at 11:39:09AM +0200, Peter Zijlstra wrote:
> bit banging the serial port is absolutely awesome, the rest of printk
> not so much.
I also have this second patch that goes on top of this.
I think I had more hacks (like using the per-cpu NMI buffers for output
instead of the
On Thu, Sep 22, 2016 at 10:36:37AM +0200, Jan Kara wrote:
> On Thu 22-09-16 10:04:36, Peter Zijlstra wrote:
> > On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > > > +static inline void assert_clock_updated(struct rq *rq)
> > > > +{
> > > > +#ifdef CONFIG_SCHED_DEBUG
> > > > +
On Thu, Sep 22, 2016 at 10:36:37AM +0200, Jan Kara wrote:
> On Thu 22-09-16 10:04:36, Peter Zijlstra wrote:
> > On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > > > +static inline void assert_clock_updated(struct rq *rq)
> > > > +{
> > > > +#ifdef CONFIG_SCHED_DEBUG
> > > > +
On Thu 22-09-16 10:04:36, Peter Zijlstra wrote:
> On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > > +static inline void assert_clock_updated(struct rq *rq)
> > > +{
> > > +#ifdef CONFIG_SCHED_DEBUG
> > > + /*
> > > + * The only reason for not seeing a clock update since the
> > >
On Thu 22-09-16 10:04:36, Peter Zijlstra wrote:
> On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > > +static inline void assert_clock_updated(struct rq *rq)
> > > +{
> > > +#ifdef CONFIG_SCHED_DEBUG
> > > + /*
> > > + * The only reason for not seeing a clock update since the
> > >
On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > +static inline void assert_clock_updated(struct rq *rq)
> > +{
> > +#ifdef CONFIG_SCHED_DEBUG
> > + /*
> > +* The only reason for not seeing a clock update since the
> > +* last rq_pin_lock() is if we're currently skipping
On Wed, Sep 21, 2016 at 05:58:27PM +0200, Petr Mladek wrote:
> > +static inline void assert_clock_updated(struct rq *rq)
> > +{
> > +#ifdef CONFIG_SCHED_DEBUG
> > + /*
> > +* The only reason for not seeing a clock update since the
> > +* last rq_pin_lock() is if we're currently skipping
Hello,
On (09/21/16 20:08), Matt Fleming wrote:
> On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
> >
> > I am not sure how the above call chain is realistic. But adding
> > WARN_ON() into the scheduler paths is risky in general.
>
> It's not clear to me why this should be the case. WARN_ON()
Hello,
On (09/21/16 20:08), Matt Fleming wrote:
> On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
> >
> > I am not sure how the above call chain is realistic. But adding
> > WARN_ON() into the scheduler paths is risky in general.
>
> It's not clear to me why this should be the case. WARN_ON()
On Wed, 21 Sep 2016, Matt Fleming wrote:
> On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
> >
> > I am not sure how the above call chain is realistic. But adding
> > WARN_ON() into the scheduler paths is risky in general.
>
> It's not clear to me why this should be the case. WARN_ON() calls
On Wed, 21 Sep 2016, Matt Fleming wrote:
> On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
> >
> > I am not sure how the above call chain is realistic. But adding
> > WARN_ON() into the scheduler paths is risky in general.
>
> It's not clear to me why this should be the case. WARN_ON() calls
On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
>
> I am not sure how the above call chain is realistic. But adding
> WARN_ON() into the scheduler paths is risky in general.
It's not clear to me why this should be the case. WARN_ON() calls have
existed in the scheduler paths since forever.
If
On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
>
> I am not sure how the above call chain is realistic. But adding
> WARN_ON() into the scheduler paths is risky in general.
It's not clear to me why this should be the case. WARN_ON() calls have
existed in the scheduler paths since forever.
If
On Wed 2016-09-21 14:38:13, Matt Fleming wrote:
> 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.
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index
On Wed 2016-09-21 14:38:13, Matt Fleming wrote:
> 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.
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index
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
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
18 matches
Mail list logo
