From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751959AbbJCHiS (ORCPT ); Sat, 3 Oct 2015 03:38:18 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:37309 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751908AbbJCHiR (ORCPT ); Sat, 3 Oct 2015 03:38:17 -0400 Date: Sat, 3 Oct 2015 09:38:13 +0200 From: Ingo Molnar To: Peter Zijlstra , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker Cc: Andrew Morton , Alexey Dobriyan , linux-kernel@vger.kernel.org, Ingo Molnar , Frederic Weisbecker Subject: Re: 4.2.2: NR_CPUS effectively being 1 bug Message-ID: <20151003073812.GA24548@gmail.com> References: <20151002204658.GA1970@p183.telecom.by> <20151002140033.ef62cd83936263311eb210d8@linux-foundation.org> <20151003065320.GE3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151003065320.GE3816@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra 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 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