On Thu, Jan 21, 2016 at 07:56:36PM +0100, Thomas Gleixner wrote:
> We really should ignore that sillyness and if people complain, make them
> complain to their HW vendor. That's the only way this crap will go away.
>
> If we just keep on supporting this completely pointless nonsense the HW folks
On Thu, Jan 21, 2016 at 07:56:36PM +0100, Thomas Gleixner wrote:
> We really should ignore that sillyness and if people complain, make them
> complain to their HW vendor. That's the only way this crap will go away.
>
> If we just keep on supporting this completely pointless nonsense the HW folks
On Thu, 21 Jan 2016, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
>
> > Actually, the handle passes dev_id in order to let the irqtimings to sort
> > out a shared interrupt and prevent double sampling. In other words, for
> > shared interrupts,
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
> > And why would that thing care about shared interruts at all? It's a legacy
> > burden and I really don't see a reason why that new thing which is
> > targeted on modern hardware should deal with them.
On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
That and we don't want to call it for each handler which returned handled.
The
called code would do two samples in a row for the same interrupt in case of
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
> > That and we don't want to call it for each handler which returned handled.
> > The
> > called code would do two samples in a row for the same interrupt in case of
> > two shared handlers which get
On 01/21/2016 11:08 AM, Peter Zijlstra wrote:
On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
Actually, the handle passes dev_id in order to let the irqtimings to sort
out a shared interrupt and prevent double sampling. In other words, for
shared interrupts, statistics should
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> Just to be sure, do you suggest to put the function declaration in
> kernel/irq/internal.h and the function definition in kernel/sched/idle-sched.c
> ?
Well obviously the declarations and stub functions should be in a header which
is accessible for
On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
> Actually, the handle passes dev_id in order to let the irqtimings to sort
> out a shared interrupt and prevent double sampling. In other words, for
> shared interrupts, statistics should be per t-uple(irq , dev_id) but that is
>
On 01/20/2016 08:28 PM, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall through to add to randomness */
On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall
On 01/20/2016 08:07 PM, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall through to add to randomness */
On 01/20/2016 06:55 PM, Thomas Gleixner wrote:
On Wed, 20 Jan 2016, Daniel Lezcano wrote:
+#ifdef CONFIG_IRQ_TIMINGS
+/**
+ * struct irqt_ops - structure to be used by the subsystem to track
+ * irq timings
+ * @alloc:called when an irqdesc is allocated
+ * @free:
On 01/21/2016 11:08 AM, Peter Zijlstra wrote:
On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
Actually, the handle passes dev_id in order to let the irqtimings to sort
out a shared interrupt and prevent double sampling. In other words, for
shared interrupts, statistics should
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
> > That and we don't want to call it for each handler which returned handled.
> > The
> > called code would do two samples in a row for the same interrupt in case of
> > two shared handlers which get
On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
> Actually, the handle passes dev_id in order to let the irqtimings to sort
> out a shared interrupt and prevent double sampling. In other words, for
> shared interrupts, statistics should be per t-uple(irq , dev_id) but that is
>
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> Just to be sure, do you suggest to put the function declaration in
> kernel/irq/internal.h and the function definition in kernel/sched/idle-sched.c
> ?
Well obviously the declarations and stub functions should be in a header which
is accessible for
On 01/20/2016 08:07 PM, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall through to add to randomness */
On 01/20/2016 08:28 PM, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall through to add to randomness */
On 01/20/2016 06:55 PM, Thomas Gleixner wrote:
On Wed, 20 Jan 2016, Daniel Lezcano wrote:
+#ifdef CONFIG_IRQ_TIMINGS
+/**
+ * struct irqt_ops - structure to be used by the subsystem to track
+ * irq timings
+ * @alloc:called when an irqdesc is allocated
+ * @free:
On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
+++ b/kernel/irq/handle.c
@@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
/* Fall
On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
That and we don't want to call it for each handler which returned handled.
The
called code would do two samples in a row for the same interrupt in case of
On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
> > And why would that thing care about shared interruts at all? It's a legacy
> > burden and I really don't see a reason why that new thing which is
> > targeted on modern hardware should deal with them.
On Thu, 21 Jan 2016, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
>
> > Actually, the handle passes dev_id in order to let the irqtimings to sort
> > out a shared interrupt and prevent double sampling. In other words, for
> > shared interrupts,
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > > Here too, ktime_get() is daft.
> >
> > What's the problem? ktime_xxx() itself or just the clock monotonic variant?
> >
> > On 99.% of the platforms
On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > Here too, ktime_get() is daft.
>
> What's the problem? ktime_xxx() itself or just the clock monotonic variant?
>
> On 99.% of the platforms ktime_get_mono_fast/raw_fast is not any slower
> than sched_clock(). The only case
On Wed, 20 Jan 2016, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Peter Zijlstra wrote:
>
> > On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> > > +++ b/kernel/irq/handle.c
> > > @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc
> > > *desc)
> > >
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> > +++ b/kernel/irq/handle.c
> > @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc
> > *desc)
> > /* Fall through to add to randomness */
> >
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> +++ b/kernel/irq/handle.c
> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> /* Fall through to add to randomness */
> case IRQ_HANDLED:
>
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> +++ b/kernel/irq/handle.c
> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> /* Fall through to add to randomness */
> case IRQ_HANDLED:
>
On Wed, 20 Jan 2016, Daniel Lezcano wrote:
> +#ifdef CONFIG_IRQ_TIMINGS
> +/**
> + * struct irqt_ops - structure to be used by the subsystem to track
> + * irq timings
> + * @alloc:called when an irqdesc is allocated
> + * @free: called when an irqdesc is free
> + *
The interrupt framework gives a lot of information and statistics about
each interrupt.
Unfortunately there is no way to measure when interrupts occur and provide
a mathematical model for their behavior which could help in predicting
their next occurence.
This framework allows for registering a
The interrupt framework gives a lot of information and statistics about
each interrupt.
Unfortunately there is no way to measure when interrupts occur and provide
a mathematical model for their behavior which could help in predicting
their next occurence.
This framework allows for registering a
The interrupt framework gives a lot of information and statistics about
each interrupt.
Unfortunately there is no way to measure when interrupts occur and provide
a mathematical model for their behavior which could help in predicting
their next occurence.
This framework allows for registering a
The interrupt framework gives a lot of information and statistics about
each interrupt.
Unfortunately there is no way to measure when interrupts occur and provide
a mathematical model for their behavior which could help in predicting
their next occurence.
This framework allows for registering a
On Wed, 20 Jan 2016, Daniel Lezcano wrote:
> +#ifdef CONFIG_IRQ_TIMINGS
> +/**
> + * struct irqt_ops - structure to be used by the subsystem to track
> + * irq timings
> + * @alloc:called when an irqdesc is allocated
> + * @free: called when an irqdesc is free
> + *
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> > +++ b/kernel/irq/handle.c
> > @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc
> > *desc)
> > /* Fall through to add to randomness */
> >
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> +++ b/kernel/irq/handle.c
> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> /* Fall through to add to randomness */
> case IRQ_HANDLED:
>
On Wed, 20 Jan 2016, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Peter Zijlstra wrote:
>
> > On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> > > +++ b/kernel/irq/handle.c
> > > @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc
> > > *desc)
> > >
On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> +++ b/kernel/irq/handle.c
> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> /* Fall through to add to randomness */
> case IRQ_HANDLED:
>
On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > Here too, ktime_get() is daft.
>
> What's the problem? ktime_xxx() itself or just the clock monotonic variant?
>
> On 99.% of the platforms ktime_get_mono_fast/raw_fast is not any slower
> than sched_clock(). The only case
On Wed, 20 Jan 2016, Peter Zijlstra wrote:
> On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > > Here too, ktime_get() is daft.
> >
> > What's the problem? ktime_xxx() itself or just the clock monotonic variant?
> >
> > On 99.% of the platforms
42 matches
Mail list logo
