From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org, rafael@kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
nicolas.pitre@linaro.org, vincent.guittot@linaro.org
Subject: Re: [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings
Date: Tue, 12 Jan 2016 12:42:15 +0100 [thread overview]
Message-ID: <5694E697.6020306@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.11.1601081616530.3575@nanos>
Hi Thomas,
thanks for taking some time to review the patches.
On 01/08/2016 04:31 PM, Thomas Gleixner wrote:
> On Wed, 6 Jan 2016, Daniel Lezcano wrote:
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +/**
>> + * timing handler to be called when an interrupt happens
>> + */
>> +typedef void (*irqt_handler_t)(unsigned int, ktime_t, void *, void *);
>> +
>> +/**
>> + * struct irqtimings - per interrupt irq timings descriptor
>> + * @handler: interrupt handler timings function
>> + * @data: pointer to the private data to be passed to the handler
>> + * @timestamp: latest interruption occurence
>
> There is no timestamp member.
>
>> + */
>> +struct irqtimings {
>> + irqt_handler_t handler;
>> + void *data;
>
> What's that data thingy for. The proposed user does not use it at all and I
> have no idea why any user would want it. All it does is provide another level
> of indirection in the hotpath.
Yes, I agree. I added this private_data field for future use in case it
would be needed but it does not make sense now.
>> +} ____cacheline_internodealigned_in_smp;
>
>> +/**
>> + * struct irqt_ops - structure to be used by the subsystem to call the
>> + * register and unregister ops when an irq is setup or freed.
>> + * @setup: registering callback
>> + * @free: unregistering callback
>> + *
>> + * The callbacks assumes the lock is held on the irq desc
>
> Crap. It's called outside of the locked region and the proposed user locks the
> descriptor itself, but that's a different story.
>
>> +static inline void free_irq_timings(unsigned int irq, void *dev_id)
>> +{
>> + ;
>
> What's the purpose of this semicolon?
Bah, old habit. I will remove it.
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +void handle_irqt_event(struct irqtimings *irqt, struct irqaction *action)
>
> static ?
>
>> +{
>> + if (irqt)
>
> This want's to use a static key.
Ok, I will look at that. I already used static keys to disable a portion
of code from sysfs but never this way.
>> + irqt->handler(action->irq, ktime_get(),
>> + action->dev_id, irqt->data);
>> +}
>> +#else
>> +#define handle_irqt_event(a, b)
>
> static inline stub if at all.
ok.
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +/*
>> + * Global variable, only used by accessor functions, currently only
>> + * one user is allowed ...
>
> That variable is static not global. And what the heck means:
>
>> ... and it is up to the caller to make sure to
>> + * setup the irq timings which are already setup.
>
> -ENOPARSE.
hmm , yes ... it is not clear :)
I should have say:
"... and it is up to the caller to register the irq timing callback for
the interrupts which are already setup."
>> + */
>> +static struct irqtimings_ops *irqtimings_ops;
>> +
>> +/**
>> + * register_irq_timings - register the ops when an irq is setup or freed
>> + *
>> + * @ops: the register/unregister ops to be called when at setup or
>> + * free time
>> + *
>> + * Returns -EBUSY if the slot is already in use, zero on success.
>> + */
>> +int register_irq_timings(struct irqtimings_ops *ops)
>> +{
>> + if (irqtimings_ops)
>> + return -EBUSY;
>> +
>> + irqtimings_ops = ops;
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * setup_irq_timings - call the timing register callback
>> + *
>> + * @desc: an irq desc structure
>
> The argument list tells a different story.
>
>> + *
>> + * Returns -EINVAL in case of error, zero on success.
>> + */
>> +int setup_irq_timings(unsigned int irq, struct irqaction *act)
>
> static is not in your book, right? These functions are only used in this file,
> so no point for having them global visible and the stubs should be local as
> well.
Ok.
>> +{
>> + if (irqtimings_ops && irqtimings_ops->setup)
>> + return irqtimings_ops->setup(irq, act);
>> + return 0;
>> +}
>
> ...
>
>> @@ -1408,6 +1469,8 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
>>
>> unregister_handler_proc(irq, action);
>>
>> + free_irq_timings(irq, dev_id);
>
> This needs to go to the point where the interrupt is already synchronized and
> the action about to be destroyed.
Ok, noted.
Thanks !
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2016-01-12 11:42 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 15:22 [RFC PATCH 0/2] IRQ based next prediction Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-08 15:31 ` Thomas Gleixner
2016-01-12 11:42 ` Daniel Lezcano [this message]
2016-01-06 15:22 ` [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-06 17:40 ` Nicolas Pitre
2016-01-07 15:42 ` Daniel Lezcano
2016-01-12 19:27 ` Nicolas Pitre
2016-01-10 22:37 ` Daniel Lezcano
2016-01-10 22:46 ` Nicolas Pitre
2016-01-10 22:58 ` Daniel Lezcano
2016-01-10 23:13 ` Nicolas Pitre
2016-01-08 15:43 ` Thomas Gleixner
2016-01-12 12:41 ` Daniel Lezcano
2016-01-12 13:42 ` Thomas Gleixner
2016-01-12 14:16 ` Daniel Lezcano
2016-01-12 14:26 ` Thomas Gleixner
2016-01-12 14:52 ` Daniel Lezcano
2016-01-12 15:12 ` Thomas Gleixner
2016-01-12 16:04 ` Daniel Lezcano
2016-01-13 9:17 ` Thomas Gleixner
2016-01-18 13:21 ` Daniel Lezcano
2016-01-20 15:41 ` Thomas Gleixner
2016-01-20 16:00 ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 17:55 ` Thomas Gleixner
2016-01-21 9:25 ` Daniel Lezcano
2016-01-21 10:27 ` Thomas Gleixner
2016-01-20 19:07 ` Peter Zijlstra
2016-01-20 19:57 ` Thomas Gleixner
2016-01-20 20:04 ` Nicolas Pitre
2016-01-20 20:20 ` Peter Zijlstra
2016-01-20 20:22 ` Thomas Gleixner
2016-01-21 9:50 ` Daniel Lezcano
2016-01-21 10:08 ` Peter Zijlstra
2016-01-21 12:38 ` Daniel Lezcano
2016-01-21 20:27 ` Thomas Gleixner
2016-01-21 13:52 ` Thomas Gleixner
2016-01-21 14:19 ` Daniel Lezcano
2016-01-21 18:56 ` Thomas Gleixner
2016-01-22 10:15 ` Peter Zijlstra
2016-01-21 9:26 ` Daniel Lezcano
2016-01-20 19:28 ` Peter Zijlstra
2016-01-21 9:53 ` Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 17:46 ` Nicolas Pitre
2016-01-20 18:44 ` Peter Zijlstra
2016-01-21 10:03 ` Daniel Lezcano
2016-01-20 19:02 ` Peter Zijlstra
2016-01-20 19:17 ` Nicolas Pitre
2016-01-20 19:29 ` Peter Zijlstra
2016-01-20 19:34 ` Peter Zijlstra
2016-01-20 19:40 ` Peter Zijlstra
2016-01-20 19:57 ` Nicolas Pitre
2016-01-20 20:22 ` Peter Zijlstra
2016-01-20 19:49 ` Thomas Gleixner
2016-01-21 13:54 ` Daniel Lezcano
2016-01-21 14:12 ` Thomas Gleixner
2016-01-20 16:00 ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 20:14 ` Nicolas Pitre
2016-01-21 13:04 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5694E697.6020306@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).