lkml.org 
[lkml]   [2015]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 4.2.2: NR_CPUS effectively being 1 bug

* 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


\
 
 \ /
  Last update: 2015-10-03 10:01    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog