All of lore.kernel.org
 help / color / mirror / Atom feed
From: psodagud@codeaurora.org
To: Thomas Gleixner <tglx@linutronix.de>
Cc: john.stultz@linaro.org, sboyd@kernel.org, tj@kernel.org,
	linux-kernel@vger.kernel.org, saravanak@google.com,
	pkondeti@codeaurora.org, Joonwoo Park <joonwoop@codeaurora.org>
Subject: Re: [PATCH v3 1/2] timer: make deferrable cpu unbound timers really not bound to a cpu
Date: Wed, 13 May 2020 12:53:48 -0700	[thread overview]
Message-ID: <dbc01cd27346bb465744b93ece2b6362@codeaurora.org> (raw)
In-Reply-To: <87a72lkx9t.fsf@nanos.tec.linutronix.de>

Hi Tglx,

On 2020-05-06 06:28, Thomas Gleixner wrote:
> Prasad Sodagudi <psodagud@codeaurora.org> writes:
>> To make all cpu unbound deferrable timers are scalable, introduce a 
>> common
>> timer base which is only for cpu unbound deferrable timers to make 
>> those
>> are indeed cpu unbound so that can be scheduled by any of non idle 
>> cpus.
>> This common timer fixes scalability issue of delayed work and all 
>> other cpu
>> unbound deferrable timer using implementations.
> 
> Scalability? That's really the wrong term here. A global timer base is
> the opposite and you really want to explain why this is not creating a
> scalability problem on large systems.
> 
>>  #ifdef CONFIG_SMP
>> +struct timer_base timer_base_deferrable;
>>  unsigned int sysctl_timer_migration = 1;
>> 
>>  DEFINE_STATIC_KEY_FALSE(timers_migration_enabled);
>> @@ -841,8 +842,14 @@ static inline struct timer_base 
>> *get_timer_cpu_base(u32 tflags, u32 cpu)
>>  	 * If the timer is deferrable and NO_HZ_COMMON is set then we need
>>  	 * to use the deferrable base.
>>  	 */
>> -	if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && (tflags & TIMER_DEFERRABLE))
>> -		base = per_cpu_ptr(&timer_bases[BASE_DEF], cpu);
>> +	if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && (tflags & TIMER_DEFERRABLE)) 
>> {
>> +#ifdef CONFIG_SMP
>> +		base = &timer_base_deferrable;
>> +#endif
> 
> There are definitely smarter ways of solving this than sprinkling
> #ifdef's around the code.

I am able to understand all other comments and I will address all those 
comments in the next patch set.
It is not clear to me how to avoid #ifdef's in this case. Could you 
please share an example here?


> 
>> +		if (tflags & TIMER_PINNED)
>> +			base = per_cpu_ptr(&timer_bases[BASE_DEF], cpu);
>> +	}
>> +
>>  	return base;
>>  }
>> @@ -1785,8 +1798,14 @@ static __latent_entropy void 
>> run_timer_softirq(struct softirq_action *h)
>>  	struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
>> 
>>  	__run_timers(base);
>> -	if (IS_ENABLED(CONFIG_NO_HZ_COMMON))
>> +	if (IS_ENABLED(CONFIG_NO_HZ_COMMON)) {
>>  		__run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
>> +#ifdef CONFIG_SMP
>> +		if (tick_do_timer_cpu == TICK_DO_TIMER_NONE ||
>> +				tick_do_timer_cpu == smp_processor_id())
>> +			__run_timers(&timer_base_deferrable);
>> +#endif
> 
> Again, this can be solved in readable ways. Just slapping #ifdefs all
> over the place is sloppy and lazy.
Sorry. I will try to address this.  It is not clear to me how to avoid 
#ifdefs in this case too.
Please provide me more information.

> 
> Aside of that accessing the tick internals here open coded is just a
> layering violation.
I will fix this and avoid using referring to tick internals here.

> 
>> +	}
>>  }
>> 
>>  /*
>> @@ -2025,6 +2044,16 @@ static void __init init_timer_cpu(int cpu)
>>  	}
>>  }
>> 
>> +#if defined(CONFIG_NO_HZ_COMMON) && defined(CONFIG_SMP)
>> +static void __init init_timer_deferrable_global(void)
>> +{
>> +	timer_base_deferrable.cpu = nr_cpu_ids;
> 
> This was obviously never tested with CONFIG_DEBUG_PER_CPU_MAPS=y as 
> this
> will simply result in out of bounds accesses.

Sure. I will test this CONFIG_DEBUG_PER_CPU_MAPS=y enabled before 
pushing the next patch set.
> 
>>  static void __init init_timer_cpus(void)
>>  {
>>  	int cpu;
>> @@ -2036,6 +2065,9 @@ static void __init init_timer_cpus(void)
>>  void __init init_timers(void)
>>  {
>>  	init_timer_cpus();
>> +#if defined(CONFIG_NO_HZ_COMMON) && defined(CONFIG_SMP)
>> +	init_timer_deferrable_global();
>> +#endif
> 
> Stub functions exist to avoid this unreadable #ifdef garbage.
Got it. I will fix this in the next patch set.

> 
> Thanks,
> 
>         tglx

  reply	other threads:[~2020-05-13 19:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02 18:28 [PATCH v3 0/2] timer: make deferrable cpu unbound timers really not bound to a cpu Prasad Sodagudi
2020-05-02 18:28 ` [PATCH v3 1/2] " Prasad Sodagudi
2020-05-04 18:11   ` kbuild test robot
2020-05-04 18:11     ` kbuild test robot
2020-05-05  0:08   ` kbuild test robot
2020-05-05  0:08     ` kbuild test robot
2020-05-06 13:28   ` Thomas Gleixner
2020-05-13 19:53     ` psodagud [this message]
2020-05-13 20:28       ` Thomas Gleixner
2020-05-13 20:55         ` psodagud
2020-05-13 21:34           ` Thomas Gleixner
2020-05-02 18:28 ` [PATCH v3 2/2] sched: Add a check for cpu unbound deferrable timers Prasad Sodagudi
2020-05-04 19:11   ` kbuild test robot
2020-05-04 19:11     ` kbuild test robot
2020-05-06 14:03   ` Thomas Gleixner

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=dbc01cd27346bb465744b93ece2b6362@codeaurora.org \
    --to=psodagud@codeaurora.org \
    --cc=john.stultz@linaro.org \
    --cc=joonwoop@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pkondeti@codeaurora.org \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.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 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.