All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	linux-rt-users@vger.kernel.org, frederic@kernel.org
Cc: mtosatti@redhat.com, Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 1/2] timers: Add pending timer bool in struct timer_base
Date: Fri, 18 Jun 2021 23:06:08 +0200	[thread overview]
Message-ID: <87pmwievcv.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20210610125945.558872-1-nsaenzju@redhat.com>

Nicolas,

On Thu, Jun 10 2021 at 14:59, Nicolas Saenz Julienne wrote:

please always Cc the relevant mailing lists and the maintainers.
MAINTAINERS exists for a reason.

> We need to efficiently check whether a timer base has no pending
> events.

'We need' is not a technical explanation. That's close to 'I want a pony'.

Please describe what you are trying to solve and why the existing
mechanisms are not good enough.

See Documentation/process/submitting-patches.rst

> So introduce a new variable in struct timer_base to do so.

The variable solves your problem? Interesting solution.

>  		base->next_expiry = bucket_expiry;
>  		base->next_expiry_recalc = false;
> +#ifdef CONFIG_PREEMPT_RT
> +		base->pending = true;
> +#endif

What is RT specific about that?

>  		trigger_dyntick_cpu(base, timer);
>  	}
>  }
> @@ -1598,6 +1602,9 @@ static unsigned long __next_timer_interrupt(struct timer_base *base)
>  	}
>  
>  	base->next_expiry_recalc = false;
> +#ifdef CONFIG_PREEMPT_RT
> +	base->pending = (next != base->clk + NEXT_TIMER_MAX_DELTA);
> +#endif

This lacks any information about the semantics of this flag:

  - When is it valid and when not?
  - What is the valid use case for this flag?

Summary of the supplied information: We need a flag, so we added one.

Sorry that's not sufficient.

Thanks,

        tglx

  


      parent reply	other threads:[~2021-06-18 21:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 12:59 [RFC 1/2] timers: Add pending timer bool in struct timer_base Nicolas Saenz Julienne
2021-06-10 12:59 ` [RFC 2/2] timers: Make sure irq_work is handled when no pending timers Nicolas Saenz Julienne
2021-06-18 22:47   ` Thomas Gleixner
2021-06-19  8:22     ` Thomas Gleixner
2021-06-22 13:44     ` Peter Zijlstra
2021-06-22 17:33       ` Jiri Olsa
2021-06-22 17:42         ` Jiri Olsa
2021-06-30 17:43   ` Alison Chaiken
2021-06-18 21:06 ` Thomas Gleixner [this message]

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=87pmwievcv.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nsaenzju@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.