From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759061AbdENSJZ (ORCPT ); Sun, 14 May 2017 14:09:25 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36394 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754719AbdENSJW (ORCPT ); Sun, 14 May 2017 14:09:22 -0400 Date: Sun, 14 May 2017 20:09:17 +0200 From: Ingo Molnar To: Yury Norov Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Arnd Bergmann , Ingo Molnar , Peter Zijlstra , Richard Henderson , Ivan Kokshaysky , Matt Turner , Akinobu Mita , Mike Galbraith Subject: Re: [PATCH] sched: remove sched_find_first_bit() Message-ID: <20170514180917.bil7xr4bqtfk6fzj@gmail.com> References: <20170513010152.13986-1-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513010152.13986-1-ynorov@caviumnetworks.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Yury Norov wrote: > sched_find_first_bit() is in fact the unrolled version of > find_first_bit(), which is theoretically faster in some cases. > But in the kernel it is called only in couple places in > kernel/sched/rt.c, and both of them are not looking like hot > paths [...] They are in terms of scheduling: pick_next_rt_entity() is in the RT scheduling fastpath. Which makes me just suspicious of how careful this patch really is: > that will doubtly achieve measurable benefit from using unrolled version of > find_first_bit() - there's no hard loops, and the execution path is not really > short. ... that's really just handwaving. Numbers please. Thanks, Ingo