Linux Power Management development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
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: Fri, 8 Jan 2016 16:31:22 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1601081616530.3575@nanos> (raw)
In-Reply-To: <1452093774-17831-2-git-send-email-daniel.lezcano@linaro.org>

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.

> +} ____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?

> +#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.

> +		irqt->handler(action->irq, ktime_get(),
> +			      action->dev_id, irqt->data);
> +}
> +#else
> +#define handle_irqt_event(a, b)

static inline stub if at all.

> +#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.

> + */
> +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.

> +{
> +	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.

Thanks,

	tglx

  reply	other threads:[~2016-01-08 15:32 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 [this message]
2016-01-12 11:42     ` Daniel Lezcano
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=alpine.DEB.2.11.1601081616530.3575@nanos \
    --to=tglx@linutronix.de \
    --cc=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=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