On 25/04/2017 15:22, Marc Zyngier wrote:
> On 25/04/17 13:51, Daniel Lezcano wrote:
>> On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
>>> On 25/04/17 10:49, Daniel Lezcano wrote:
On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>>>
>>> [...]
>>>
>> +static
On 25/04/17 13:51, Daniel Lezcano wrote:
> On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
>> On 25/04/17 10:49, Daniel Lezcano wrote:
>>> On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>>
>> [...]
>>
> +static inline void setup_timings(struct irq_desc *desc,
On Tue, Apr 25, 2017 at 12:22:30PM +0200, Christoffer Dall wrote:
> On Tue, Apr 25, 2017 at 11:49:27AM +0200, Daniel Lezcano wrote:
>
> [...]
>
> > >
> > > The idle code is very much *not* aware of anything concerning that guest
> > > timer.
> >
> > Just for my own curiosity, if there are two
On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
> On 25/04/17 10:49, Daniel Lezcano wrote:
> > On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>
> [...]
>
> >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction
> >>> *act)
> >>> +{
> >>> + /*
On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
[ ... ]
> Maybe you could explain why you think this interrupt is relevant to what
> you're trying to achieve?
> >>>
> >>> If this interrupt does not happen on the host, we don't care.
> >>
> >> All interrupts happen on the
On Tue, Apr 25, 2017 at 08:38:56AM +0100, Marc Zyngier wrote:
> On 24/04/17 20:59, Daniel Lezcano wrote:
> > On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
> >> On 24/04/17 19:59, Daniel Lezcano wrote:
> >>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> On
On 24/04/17 20:59, Daniel Lezcano wrote:
> On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
>> On 24/04/17 19:59, Daniel Lezcano wrote:
>>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
On 24/04/17 15:01, Daniel Lezcano wrote:
> In the next changes, we track
On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote:
> On 24/04/17 19:59, Daniel Lezcano wrote:
> > On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> >> On 24/04/17 15:01, Daniel Lezcano wrote:
> >>> In the next changes, we track when the interrupts occur in order to
> >>>
On Mon, Apr 24, 2017 at 04:01:31PM +0200, Daniel Lezcano wrote:
> In the next changes, we track when the interrupts occur in order to
> statistically compute when is supposed to happen the next interrupt.
>
> In all the interruptions, it does not make sense to store the timer interrupt
>
On 24/04/17 19:59, Daniel Lezcano wrote:
> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
>> On 24/04/17 15:01, Daniel Lezcano wrote:
>>> In the next changes, we track when the interrupts occur in order to
>>> statistically compute when is supposed to happen the next interrupt.
>>>
On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> On 24/04/17 15:01, Daniel Lezcano wrote:
> > In the next changes, we track when the interrupts occur in order to
> > statistically compute when is supposed to happen the next interrupt.
> >
> > In all the interruptions, it does not
On 24/04/17 15:01, Daniel Lezcano wrote:
> In the next changes, we track when the interrupts occur in order to
> statistically compute when is supposed to happen the next interrupt.
>
> In all the interruptions, it does not make sense to store the timer interrupt
> occurences and try to predict
In the next changes, we track when the interrupts occur in order to
statistically compute when is supposed to happen the next interrupt.
In all the interruptions, it does not make sense to store the timer interrupt
occurences and try to predict the next interrupt as when know the expiration
time.
13 matches
Mail list logo
