From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755968AbZBWQdf (ORCPT ); Mon, 23 Feb 2009 11:33:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753240AbZBWQd0 (ORCPT ); Mon, 23 Feb 2009 11:33:26 -0500 Received: from gir.skynet.ie ([193.1.99.77]:45078 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753073AbZBWQd0 (ORCPT ); Mon, 23 Feb 2009 11:33:26 -0500 Date: Mon, 23 Feb 2009 16:33:23 +0000 From: Mel Gorman To: Christoph Lameter Cc: Linux Memory Management List , Pekka Enberg , Rik van Riel , KOSAKI Motohiro , Johannes Weiner , Nick Piggin , Linux Kernel Mailing List , Lin Ming , Zhang Yanmin Subject: Re: [PATCH 04/20] Convert gfp_zone() to use a table of precalculated values Message-ID: <20090223163322.GN6740@csn.ul.ie> References: <1235344649-18265-1-git-send-email-mel@csn.ul.ie> <1235344649-18265-5-git-send-email-mel@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 23, 2009 at 10:23:52AM -0500, Christoph Lameter wrote: > On Sun, 22 Feb 2009, Mel Gorman wrote: > > > Every page allocation uses gfp_zone() to calcuate what the highest zone > > allowed by a combination of GFP flags is. This is a large number of branches > > to have in a fast path. This patch replaces the branches with a lookup > > table that is calculated at boot-time and stored in the read-mostly section > > so it can be shared. This requires __GFP_MOVABLE to be redefined but it's > > debatable as to whether it should be considered a zone modifier or not. > > Are you sure that this is a benefit? I haven't proved it, but my thinking was that this was a crapload of branches in fast paths that will be mispredicted. I tried profiling the RETIRED_MISPREDICTED_BRANCH_INSTRUCTIONS event and noticed there were large numbers in this general area. However, the profile counters for this event seem to be very difficult to isolate to a specific area of code so it's difficult to be 100% certain. > Jumps are forward and pretty short > and the compiler is optimizing a branch away in the current code. > I was concerned with mispredictions here rather than the actual assembly and gfp_zone is inlined so it's lot of branches introduced in a lot of paths. > > 0xffffffff8027bde8 : mov %esi,-0x58(%rbp) > 0xffffffff8027bdeb : movq $0xffffffff80278cd0,-0x48(%rbp) > 0xffffffff8027bdf3 : test $0x1,%r8b > 0xffffffff8027bdf7 : mov 0x620(%rax),%rax > 0xffffffff8027bdfe : mov %rax,-0x88(%rbp) > 0xffffffff8027be05 : jne 0xffffffff8027be2c > 0xffffffff8027be07 : mov $0x1,%r14d > 0xffffffff8027be0d : test $0x4,%r8b > 0xffffffff8027be11 : jne 0xffffffff8027be2c > 0xffffffff8027be13 : xor %r14d,%r14d > 0xffffffff8027be16 : and $0x100002,%r8d > 0xffffffff8027be1d : cmp $0x100002,%r8d > 0xffffffff8027be24 : sete %r14b > 0xffffffff8027be28 : add $0x2,%r14d > 0xffffffff8027be2c : mov %gs:0x8,%rdx > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab