Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752605AbbDAIac (ORCPT ); Wed, 1 Apr 2015 04:30:32 -0400 Received: from mgwkm02.jp.fujitsu.com ([202.219.69.169]:42001 "EHLO mgwkm02.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbbDAIa2 (ORCPT ); Wed, 1 Apr 2015 04:30:28 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2 Message-ID: <551BAC91.208@jp.fujitsu.com> Date: Wed, 1 Apr 2015 17:30:09 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tejun Heo CC: Gu Zheng , , , , , Subject: Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed References: <1427336275-32066-1-git-send-email-guz.fnst@cn.fujitsu.com> <55137935.5080301@jp.fujitsu.com> <55139340.8070201@cn.fujitsu.com> <20150326151850.GD1953@htj.duckdns.org> <551436F2.5020804@jp.fujitsu.com> <55191C3D.8070800@cn.fujitsu.com> <551A3A01.7030707@jp.fujitsu.com> <20150331152822.GE9974@htj.duckdns.org> <551B5E0F.1020302@jp.fujitsu.com> <20150401030242.GL9974@htj.duckdns.org> In-Reply-To: <20150401030242.GL9974@htj.duckdns.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2429 Lines: 58 On 2015/04/01 12:02, Tejun Heo wrote: > On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote: >> Now, hot-added cpus will have the lowest free cpu id. >> >> Because of this, in most of systems which has only cpu-hot-add, cpu-ids are always >> contiguous even after cpu hot add. >> In enterprise, this would be considered as imcompatibility. >> >> determining cpuid <-> lapicid at boot will make cpuids sparse. That may corrupt >> exisiting script or configuration/resource management software. > > Ugh... so, cpu number allocation on hot-add is part of userland > interface that we're locked into? We checked most of RHEL7 packages and didn't find a problem yet. But, for examle, we know some performance test team's test program assumed contiguous cpuids and it failed. It was an easy case because we can ask them to fix the application but I guess there will be some amount of customers that cpuids are contiguous. > Tying hotplug and id allocation > order together usually isn't a good idea. What if the cpu up fails > while running the notifiers? The ID is already allocated and the next > cpu being brought up will be after a hole anyway. Is this even > actually gonna affect userland? > Maybe. It's not fail-safe but.... In general, all kernel engineers (and skilled userland engineers) knows that cpuids cannot be always contiguous and cpuids/nodeids should be checked before running programs. I think most of engineers should be aware of that but many users have their own assumption :( Basically, I don't have strong objections, you're right technically. In summary... - users should not assume cpuids are contiguous. - all possible ids should be fixed at boot time. - For uses, some clarification document should be somewhere in Documenatation. So, Gu-san 1) determine all possible ids at boot. 2) clarify cpuid/nodeid can have hole because of 1) in Documenation. 3) It would be good if other guys give us ack. In future, I myself thinks naming system like udev for cpuid/numaid is necessary, at last. Can that renaming feature can be cgroup/namespace feature ? If possible, all container can have cpuids starting from 0. Thanks, -Kame -- 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/