Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1238620 > unrolled thread

Re: 4.2.2: NR_CPUS effectively being 1 bug

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1238620 — Re: 4.2.2: NR_CPUS effectively being 1 bug

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?

It should be pretty easy to debug.  I'd guess that the problem is in
the area of x86 SMP bringup and there might even be a nasty message in
the dmesg explaining what went wrong?

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 4.2.2 Kernel Configuration
> #
> CONFIG_64BIT=y
> ...
>
--
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/

[toc] | [next] | [standalone]

#1238747

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

[toc] | [prev] | [next] | [standalone]

#1238750

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

[toc] | [prev] | [next] | [standalone]

#1238769

On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> * 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?

Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
so now if nohz_full is ever turned on, that CPU is gone from the generic
pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.

Lovely eh?

	-Mike

--
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/

[toc] | [prev] | [next] | [standalone]

#1238771

* Mike Galbraith <umgwanakikbuti@gmail.com> wrote:

> On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > * 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?
> 
> Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> so now if nohz_full is ever turned on, that CPU is gone from the generic
> pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> 
> Lovely eh?

Which commit is that? Needs to be reverted...

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/

[toc] | [prev] | [next] | [standalone]

#1238775

On Sat, 2015-10-03 at 10:18 +0200, Ingo Molnar wrote:
> * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> 
> > On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > > * 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?
> > 
> > Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> > and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> > so now if nohz_full is ever turned on, that CPU is gone from the generic
> > pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> > 
> > Lovely eh?
> 
> Which commit is that? Needs to be reverted...

8cb9764f nohz: Set isolcpus when nohz_full is set

That's the one that makes them all automatically go away.

	-Mike


--
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/

[toc] | [prev] | [next] | [standalone]

#1238778

* Mike Galbraith <umgwanakikbuti@gmail.com> wrote:

> On Sat, 2015-10-03 at 10:18 +0200, Ingo Molnar wrote:
> > * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> > 
> > > On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > > > * 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?
> > > 
> > > Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> > > and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> > > so now if nohz_full is ever turned on, that CPU is gone from the generic
> > > pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> > > 
> > > Lovely eh?
> > 
> > Which commit is that? Needs to be reverted...
> 
> 8cb9764f nohz: Set isolcpus when nohz_full is set
> 
> That's the one that makes them all automatically go away.

Ok, looks like a patch with good intentions but bad effects. Mind sending a revert 
patch, changelogged, signed off?

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/

[toc] | [prev] | [next] | [standalone]

#1238830

On Sat, 2015-10-03 at 10:52 +0200, Ingo Molnar wrote:
> * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> 
> > On Sat, 2015-10-03 at 10:18 +0200, Ingo Molnar wrote:
> > > * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> > > 
> > > > On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > > > > * 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?
> > > > 
> > > > Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> > > > and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> > > > so now if nohz_full is ever turned on, that CPU is gone from the generic
> > > > pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> > > > 
> > > > Lovely eh?
> > > 
> > > Which commit is that? Needs to be reverted...
> > 
> > 8cb9764f nohz: Set isolcpus when nohz_full is set
> > 
> > That's the one that makes them all automatically go away.
> 
> Ok, looks like a patch with good intentions but bad effects. Mind sending a revert 
> patch, changelogged, signed off?

No.  They know.

	-Mike

--
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/

[toc] | [prev] | [next] | [standalone]

#1238847

On Sat, Oct 03, 2015 at 02:04:44PM +0200, Mike Galbraith wrote:
> On Sat, 2015-10-03 at 10:52 +0200, Ingo Molnar wrote:
> > Ok, looks like a patch with good intentions but bad effects. Mind sending a revert 
> > patch, changelogged, signed off?
> 
> No.  They know.

The reason for this patch is that NO_HZ_FULL is only useful on a CPU if no task
other than the desired one can be scheduled on it. Hence the cpu_isolated_map.

Only those who enable NO_HZ_FULL_ALL by accident do complain, not those who
really use it so far. At least it makes people realize their mistake.

That said I never liked that cpu_isolated_map. And some regular non-isolation
work may be needed to be done even on NO_HZ_FULL_ALL machines and it that
case we get screwed.

So I should revert that and defer that isolation work to explicit affinity
setting or cpusets.
--
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/

[toc] | [prev] | [next] | [standalone]

#1238851

On Sat, 2015-10-03 at 14:31 +0200, Frederic Weisbecker wrote:
> On Sat, Oct 03, 2015 at 02:04:44PM +0200, Mike Galbraith wrote:
> > On Sat, 2015-10-03 at 10:52 +0200, Ingo Molnar wrote:
> > > Ok, looks like a patch with good intentions but bad effects. Mind sending a revert 
> > > patch, changelogged, signed off?
> > 
> > No.  They know.
> 
> The reason for this patch is that NO_HZ_FULL is only useful on a CPU if no task
> other than the desired one can be scheduled on it. Hence the cpu_isolated_map.

Yes, but makes it needlessly static.

> Only those who enable NO_HZ_FULL_ALL by accident do complain, not those who
> really use it so far. At least it makes people realize their mistake.
> 
> That said I never liked that cpu_isolated_map. And some regular non-isolation
> work may be needed to be done even on NO_HZ_FULL_ALL machines and it that
> case we get screwed.

ATM, using nohz_full CPUs for generic work has a high price, but those
CPUs work just fine.  Andy is allegedly gonna make that overhead go
away, at which time dynamic sets become a much more attractive, but you
can do that now.

> So I should revert that and defer that isolation work to explicit affinity
> setting or cpusets.

Yay.

	-Mike


--
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/

[toc] | [prev] | [next] | [standalone]

#1238833

On Sat, Oct 03, 2015 at 10:15:48AM +0200, Mike Galbraith wrote:
> On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > * 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?
> 
> Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> so now if nohz_full is ever turned on, that CPU is gone from the generic
> pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> 
> Lovely eh?

Very clever. :^)

NO_HZ_FULL_ALL=n helps, thanks everyone.

I had it enabled since 3.10 for some reason.
--
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/

[toc] | [prev] | [next] | [standalone]

#1238835

On Sat, 2015-10-03 at 15:14 +0300, Alexey Dobriyan wrote:
> On Sat, Oct 03, 2015 at 10:15:48AM +0200, Mike Galbraith wrote:
> > On Sat, 2015-10-03 at 09:38 +0200, Ingo Molnar wrote:
> > > * 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?
> > 
> > Simple.  Rik made it such that cpu_isolated_map is immune to cpusets,
> > and Chris made tick_nohz_full_mask automatically set cpu_isolated_map,
> > so now if nohz_full is ever turned on, that CPU is gone from the generic
> > pool forever, with obvious consequences for CONFIG_NO_HZ_FULL_ALL.
> > 
> > Lovely eh?
> 
> Very clever. :^)
> 
> NO_HZ_FULL_ALL=n helps, thanks everyone.
> 
> I had it enabled since 3.10 for some reason.

Dave Jones was #1, I don't recall #2, but you're at least victim #3.

	-Mike

--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web