From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by kanga.kvack.org (Postfix) with ESMTP id C1CB9900002 for ; Fri, 11 Jul 2014 11:33:06 -0400 (EDT) Received: by mail-qg0-f45.google.com with SMTP id f51so1066286qge.18 for ; Fri, 11 Jul 2014 08:33:06 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [2607:f8b0:400d:c04::234]) by mx.google.com with ESMTPS id l74si3950656qgl.76.2014.07.11.08.33.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 08:33:05 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so1076822qge.39 for ; Fri, 11 Jul 2014 08:33:05 -0700 (PDT) Date: Fri, 11 Jul 2014 11:33:02 -0400 From: Tejun Heo Subject: Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node Message-ID: <20140711153302.GA30865@htj.dyndns.org> References: <1405064267-11678-1-git-send-email-jiang.liu@linux.intel.com> <1405064267-11678-8-git-send-email-jiang.liu@linux.intel.com> <20140711144205.GA27706@htj.dyndns.org> <20140711152156.GB29137@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140711152156.GB29137@htj.dyndns.org> Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Jiang Liu , Andrew Morton , Mel Gorman , David Rientjes , Mike Galbraith , Peter Zijlstra , "Rafael J . Wysocki" , Vladimir Davydov , Johannes Weiner , "Kirill A. Shutemov" , Rik van Riel , Wanpeng Li , Zhang Yanfei , Catalin Marinas , Jianyu Zhan , malc , Joonsoo Kim , Fabian Frederick , Tony Luck , linux-mm@kvack.org, linux-hotplug@vger.kernel.org, linux-kernel@vger.kernel.org On Fri, Jul 11, 2014 at 11:21:56AM -0400, Tejun Heo wrote: > Even if that's the case, there's no reason to burden everyone with > this distinction. Most users just wanna say "I'm on this node. > Please allocate considering that". There's nothing wrong with using > numa_node_id() for that. Also, this is minor but don't we also lose fallback information by doing this from the caller? Please consider the following topology where each hop is the same distance. A - B - X - C - D Where X is the memless node. num_mem_id() on X would return either B or C, right? If B or C can't satisfy the allocation, the allocator would fallback to A from B and D for C, both of which aren't optimal. It should first fall back to C or B respectively, which the allocator can't do anymoe because the information is lost when the caller side performs numa_mem_id(). Seems pretty misguided to me. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org