From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761744AbcLTN0s (ORCPT ); Tue, 20 Dec 2016 08:26:48 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:33197 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752426AbcLTN0q (ORCPT ); Tue, 20 Dec 2016 08:26:46 -0500 Date: Tue, 20 Dec 2016 14:26:43 +0100 From: Michal Hocko To: Mel Gorman Cc: Jia He , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Johannes Weiner , Joonsoo Kim , Taku Izumi Subject: Re: [PATCH RFC 1/1] mm, page_alloc: fix incorrect zone_statistics data Message-ID: <20161220132643.GG3769@dhcp22.suse.cz> References: <1481522347-20393-1-git-send-email-hejianet@gmail.com> <1481522347-20393-2-git-send-email-hejianet@gmail.com> <20161220091814.GC3769@dhcp22.suse.cz> <20161220131040.f5ga5426dduh3mhu@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220131040.f5ga5426dduh3mhu@techsingularity.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 20-12-16 13:10:40, Mel Gorman wrote: > On Tue, Dec 20, 2016 at 10:18:14AM +0100, Michal Hocko wrote: > > On Mon 12-12-16 13:59:07, Jia He wrote: > > > In commit b9f00e147f27 ("mm, page_alloc: reduce branches in > > > zone_statistics"), it reconstructed codes to reduce the branch miss rate. > > > Compared with the original logic, it assumed if !(flag & __GFP_OTHER_NODE) > > > z->node would not be equal to preferred_zone->node. That seems to be > > > incorrect. > > > > I am sorry but I have hard time following the changelog. It is clear > > that you are trying to fix a missed NUMA_{HIT,OTHER} accounting > > but it is not really clear when such thing happens. You are adding > > preferred_zone->node check. preferred_zone is the first zone in the > > requested zonelist. So for the most allocations it is a node from the > > local node. But if something request an explicit numa node (without > > __GFP_OTHER_NODE which would be the majority I suspect) then we could > > indeed end up accounting that as a NUMA_MISS, NUMA_FOREIGN so the > > referenced patch indeed caused an unintended change of accounting AFAIU. > > > > This is a similar concern to what I had. If the preferred zone, which is > the first valid usable zone, is not a "hit" for the statistics then I > don't know what "hit" is meant to mean. But the first valid usable zone is defined based on the requested numa node. Unless the requested node is memoryless then we should have a hit, no? -- Michal Hocko SUSE Labs