Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1215794imu; Mon, 5 Nov 2018 16:12:17 -0800 (PST) X-Google-Smtp-Source: AJdET5dMrdr4+QXvq7VjIo0PTn/TeYH24wqXIKhw/EUn9j9SSM1QUmdFGcpA7c/An2vHnuGRYIzH X-Received: by 2002:a17:902:e00a:: with SMTP id ca10-v6mr23613651plb.166.1541463136976; Mon, 05 Nov 2018 16:12:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541463136; cv=none; d=google.com; s=arc-20160816; b=JyDchm0EoNzYxHH9eB/ZHBIPvSmx9df+XWOGgQp2ZZ140d71AY4HVCUFqB3GHAtcBc qSm3fv3YfdCwwa1vY8Tz0pMLLtt3H6Fr7tnlJ7JFU61YUAwAj8JMWzNbxwP8IKW7B04l WE48TDwB+W5yV3mjX/nW1pa44ekvurc5RxY9YBH9hFPD24Wb06kRTls04jccFTpKldDM Vt/mg+89KMJkhp3xJdZCgXEZaybpF0z3BnWeqCX4ujf1DrYt/iuKRUI92uURr9ys69YN gTy9ZpA094faZr5M7uFxI50TJFwwym6/Vuf1IIHEpRrNm4Lnm+MCx0fmm/GMFfeH0itw k60w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wj8+MP0Q+X4/kErEU87GH8+TuYm6uQfnz8mN/PS1sCA=; b=SunURNBfJdWa0G+moC/TXoNxoYbwEKXjBIoWTeRECYs+Nz6IFXXa2c0hXrnDV2Ij2d 25gR8E3cFD0J0fBHze/ueHeHRTPocLQVymK1PZG3CMU/acBDfQrinQxpBoAKwtNLT5nD HaY4A0mwfnInfOLdNhrubo/eHpq7UlK6vUzGDs0/e16gA35GjPqLMc02/5BJrrPzHXct +3hsOcVQIvRaw+sHFMNVHu9YQDJm0z5Ciqb94Fcgr9VUwG1enkMgrEv9iBvo7Oag9vJ4 7veZkVDX6Fj3MLra6TLUWjxeIUTCF/dGaKYMcKQHTeTFZUcItYvZhGiOKJ2f0xLRICr0 dQ/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PxMHkqmv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o16si7790786pgd.117.2018.11.05.16.12.01; Mon, 05 Nov 2018 16:12:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PxMHkqmv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727560AbeKFJdh (ORCPT + 99 others); Tue, 6 Nov 2018 04:33:37 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:54983 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbeKFJdh (ORCPT ); Tue, 6 Nov 2018 04:33:37 -0500 Received: by mail-it1-f194.google.com with SMTP id d6so15511010itl.4 for ; Mon, 05 Nov 2018 16:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wj8+MP0Q+X4/kErEU87GH8+TuYm6uQfnz8mN/PS1sCA=; b=PxMHkqmvOyilx5T7xSJMKsvcmKY5aK9V1OWt2jkknnycevkyIaLh1dNhGT6QNEApe4 aU0WSOooN7ctM6E0iBorMiMhgP2OzQxEdZTu4Mk6apG3E38CPK+epXgfyr7jmqpzTRO6 dr32Y3AyauJuXYQslRR2BUZHbgwKToT5pWTMghj94PV7Ka3EfrjHlwTYl4q2NDW0h21g 0myyvt34mugKL2ZLeESPUxyvjXwdtBgBvC1viTOzxEkX4StWufF/tHxVJ+NQegmXqcei 4gocNj3ROGpsFxacny+jPBYdf+QMpq2p3ovsqjD6u8I9m41BfNP30VAQRYyd3lN/K3Cu zGtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wj8+MP0Q+X4/kErEU87GH8+TuYm6uQfnz8mN/PS1sCA=; b=SEqcwjQa04Y0Pj7dsN7AQ1y94DhQXOPr0xi/L8zLbt1yhK0HxFlWJbFTKAaAeQKc+1 LsfQFKynv279Tep8teo/c5UUZRmUacHoc11ZbHZk6uQh+SdS5XqV1r3Mxeq6Q6tZOQNA cQCkaMFKtmiA1E76h8PZXDbUbsx6D3q0fczUJG3FmdPq/3nPBMMGBZNaUmL5UtchVPcF pnAwAPJhXkut8KGHQ3GhN0Iq0iiMNB0Z1F3HSVCSbRCuq0Fvi+H7FfK4qGmf3FZTWuPA bfZFhgYcU0ZpaNRVJJnGfVnrLBdybBKjmDE3Jz/TzEnY+SS8ItXx1q+aGXUxcl+C2BaU JzTA== X-Gm-Message-State: AGRZ1gICr94tOf0tgV7aADPb39y+5Wvq578XgP6UZ0pGwcWNQ3bd81wD AodRMoo8IPXAEzT6uf8uQbi8O9xf+YUZFDpAzN4= X-Received: by 2002:a24:e385:: with SMTP id d127-v6mr282274ith.6.1541463076269; Mon, 05 Nov 2018 16:11:16 -0800 (PST) MIME-Version: 1.0 References: <20181105204000.129023-1-bvanassche@acm.org> <20181105131305.574d85469f08a4b76592feb6@linux-foundation.org> <1541454489.196084.157.camel@acm.org> <1541457654.196084.159.camel@acm.org> <1541462466.196084.163.camel@acm.org> In-Reply-To: <1541462466.196084.163.camel@acm.org> From: Alexander Duyck Date: Mon, 5 Nov 2018 16:11:04 -0800 Message-ID: Subject: Re: [PATCH] slab.h: Avoid using & for logical and of booleans To: bvanassche@acm.org Cc: linux@rasmusvillemoes.dk, Andrew Morton , LKML , Vlastimil Babka , Mel Gorman , Christoph Lameter , guro@fb.com, Pekka Enberg , David Rientjes , Joonsoo Kim , linux-mm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 5, 2018 at 4:01 PM Bart Van Assche wrote: > > On Mon, 2018-11-05 at 14:48 -0800, Alexander Duyck wrote: > > On Mon, Nov 5, 2018 at 2:41 PM Bart Van Assche wrote: > > > How about this version, still untested? My compiler is able to evaluate > > > the switch expression if the argument is constant. > > > > > > static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags) > > > { > > > - int is_dma = 0; > > > - int type_dma = 0; > > > - int is_reclaimable; > > > + unsigned int dr = !!(flags & __GFP_RECLAIMABLE); > > > > > > #ifdef CONFIG_ZONE_DMA > > > - is_dma = !!(flags & __GFP_DMA); > > > - type_dma = is_dma * KMALLOC_DMA; > > > + dr |= !!(flags & __GFP_DMA) << 1; > > > #endif > > > > > > - is_reclaimable = !!(flags & __GFP_RECLAIMABLE); > > > - > > > /* > > > * If an allocation is both __GFP_DMA and __GFP_RECLAIMABLE, return > > > * KMALLOC_DMA and effectively ignore __GFP_RECLAIMABLE > > > */ > > > - return type_dma + (is_reclaimable & !is_dma) * KMALLOC_RECLAIM; > > > + switch (dr) { > > > + default: > > > + case 0: > > > + return 0; > > > + case 1: > > > + return KMALLOC_RECLAIM; > > > + case 2: > > > + case 3: > > > + return KMALLOC_DMA; > > > + } > > > } > > > > Doesn't this defeat the whole point of the code which I thought was to > > avoid conditional jumps and branches? Also why would you bother with > > the "dr" value when you could just mask the flags value and switch on > > that directly? > > Storing the relevant bits of 'flags' in the 'dr' variable avoids that the > bit selection expressions have to be repeated and allows to use a switch > statement instead of multiple if / else statements. Really they shouldn't have to be repeated. You essentially have just 3 cases. 0, __GFP_RECLAIMABLE, and the default case. > Most kmalloc() calls pass a constant to the gfp argument. That allows the > compiler to evaluate kmalloc_type() at compile time. So the conditional jumps > and branches only appear when the gfp argument is not a constant. What makes > you think it is important to optimize for that case? > > Bart. I didn't really think it was all that important to optimize, but I thought that was what you were trying to maintain with the earlier patch since it was converting things to a table lookup. If we really don't care then why even bother with the switch statement anyway? It seems like you could just do one ternary operator and be done with it. Basically all you need is: return (defined(CONFIG_ZONE_DMA) && (flags & __GFP_DMA)) ? KMALLOC_DMA : (flags & __GFP_RECLAIMABLE) ? KMALLOC_RECLAIM : 0; Why bother with all the extra complexity of the switch statement? Thanks. - Alex