From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753182AbcB2RiA (ORCPT ); Mon, 29 Feb 2016 12:38:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:44563 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751447AbcB2Rh7 convert rfc822-to-8bit (ORCPT ); Mon, 29 Feb 2016 12:37:59 -0500 Date: Mon, 29 Feb 2016 09:37:47 -0800 From: Davidlohr Bueso To: Ingo Molnar Cc: kernel test robot , Mel Gorman , lkp@01.org, LKML , Sebastian Andrzej Siewior , Peter Zijlstra , Mel Gorman , Linus Torvalds , Hugh Dickins , Darren Hart , Chris Mason , Thomas Gleixner , Davidlohr Bueso , Peter Zijlstra Subject: Re: [lkp] [futex] 65d8fc777f: +25.6% will-it-scale.per_process_ops Message-ID: <20160229173747.GA17288@linux-uzut.site> References: <871t7vzze1.fsf@yhuang-dev.intel.com> <20160229093708.GA21037@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20160229093708.GA21037@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Feb 2016, Ingo Molnar wrote: > >* kernel test robot wrote: > >> FYI, we noticed the below changes on >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >> commit 65d8fc777f6dcfee12785c057a6b57f679641c90 ("futex: Remove requirement for >> lock_page() in get_futex_key()") > >I have asked for this before, but let me try again: could you _PLEASE_ make these >emails more readable? > >For example what are the 'below changes'? Changes in the profile output? Profiles >always change from run to run, so that alone is not informative. > >Also, there are a lot of changes - which ones prompted the email to be generated? > >All in one, this email is hard to parse, because it just dumps a lot of >information with very little explanatory structure for someone not versed in their >format. Please try to create an easy to parse 'story' that leads the reader >towards what you want these emails to tell - not just a raw dump of seemingly >unconnected pieces of data ... >↓ >Thanks, > > Ingo > >> >> >> ========================================================================================= >> compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase: >> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/lkp-sbx04/futex1/will-it-scale If I'm reading this correctly, it is similar to what I measured wrt ~lockleless get_futex_key() stuff using the perf runs, with similar performance improvement numbers (per process/thread ops). The futex1 test will just pound on FUTEX_WAKE without anyone actually blocked on a futex, so it mainly measures the key/hashing part of the operation. Thanks, Davidlohr