Re: 4.2.2: NR_CPUS effectively being 1 bug

From	Ingo Molnar <mingo@kernel.org>
Newsgroups	linux.kernel
Subject	Re: 4.2.2: NR_CPUS effectively being 1 bug
Date	2015-10-03 09:40 +0200
Message-ID	<qfpAd-3DX-1@gated-at.bofh.it> (permalink)
References	<qffrc-5YK-7@gated-at.bofh.it> <qffKy-6Av-23@gated-at.bofh.it> <qfoXw-2Gd-15@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Oct 02, 2015 at 02:00:33PM -0700, Andrew Morton wrote:
> > On Fri, 2 Oct 2015 23:46:59 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > 
> > > FYI, I've upgraded from 4.1.7 to 4.2.1 (and retested with 4.2.2) and
> > > everything is scheduled on 1 CPU out of 4 (i5 760).
> > > 
> > > 	$ sudo cat /proc/1/status | grep cpu -i
> > > 	Cpus_allowed:   1
> > > 	Cpus_allowed_list:      0
> > > 
> > > Every process inherits this tiny cpumask.
> > 
> > Sell the other CPUs on ebay?
> > 
> > I haven't seen such a report before - maybe it rings a bell with Peter
> > & Ingo?
> 
> I think this is related to some NO_HZ_FULL quackery. People seem to have
> enabled stuff they've really no sane reason for.

So the question is, is CONFIG_NO_HZ_FULL_ALL=y enabled? If yes then please disable 
it.

Frederic, is there a fix for that? The Kconfig help text for CONFIG_NO_HZ_FULL_ALL 
says::

 CONFIG_NO_HZ_FULL_ALL:

 If the user doesn't pass the nohz_full boot option to
 define the range of full dynticks CPUs, consider that all
 CPUs in the system are full dynticks by default.
 Note the boot CPU will still be kept outside the range to
 handle the timekeeping duty.

I can see people enabling that. Why are all CPUs lost if it's done?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

Re: 4.2.2: NR_CPUS effectively being 1 bug Andrew Morton <akpm@linux-foundation.org> - 2015-10-02 23:10 +0200
  Re: 4.2.2: NR_CPUS effectively being 1 bug Peter Zijlstra <peterz@infradead.org> - 2015-10-03 09:00 +0200
    Re: 4.2.2: NR_CPUS effectively being 1 bug Ingo Molnar <mingo@kernel.org> - 2015-10-03 09:40 +0200
      Re: 4.2.2: NR_CPUS effectively being 1 bug Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-03 10:20 +0200
        Re: 4.2.2: NR_CPUS effectively being 1 bug Ingo Molnar <mingo@kernel.org> - 2015-10-03 10:20 +0200
          Re: 4.2.2: NR_CPUS effectively being 1 bug Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-03 10:30 +0200
            Re: 4.2.2: NR_CPUS effectively being 1 bug Ingo Molnar <mingo@kernel.org> - 2015-10-03 11:00 +0200
              Re: 4.2.2: NR_CPUS effectively being 1 bug Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-03 14:10 +0200
                Re: 4.2.2: NR_CPUS effectively being 1 bug Frederic Weisbecker <fweisbec@gmail.com> - 2015-10-03 14:40 +0200
                Re: 4.2.2: NR_CPUS effectively being 1 bug Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-03 14:50 +0200
        Re: 4.2.2: NR_CPUS effectively being 1 bug Alexey Dobriyan <adobriyan@gmail.com> - 2015-10-03 14:20 +0200
          Re: 4.2.2: NR_CPUS effectively being 1 bug Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-03 14:30 +0200

csiph-web