From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752183AbcHKWI7 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 11 Aug 2016 18:08:59 -0400
Received: from verein.lst.de ([213.95.11.211]:43350 "EHLO newverein.lst.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750998AbcHKWI5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 11 Aug 2016 18:08:57 -0400
Date: Fri, 12 Aug 2016 00:08:54 +0200
From: Christoph Hellwig <hch@lst.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Huang, Ying" <ying.huang@intel.com>, Christoph Hellwig <hch@lst.de>,
        Dave Chinner <david@fromorbit.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Bob Peterson <rpeterso@redhat.com>,
        Wu Fengguang <fengguang.wu@intel.com>, LKP <lkp@01.org>
Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6%
	regression
Message-ID: <20160811220854.GA30146@lst.de>
References: <CA+55aFyQ6cjKOQZKEuQV9ch+aerW1Q6uGdv+pCS81rX0yjyR6w@mail.gmail.com> <8760r816wf.fsf@yhuang-mobile.sh.intel.com> <CA+55aFy=xeEKgfHWisfxsZNqrgMJxvKvhrWrPmdpMxu0pnOXig@mail.gmail.com> <20160811155721.GA23015@lst.de> <CA+55aFyVqdk0p6pmEx_gOs_AiH0TJ23ZEUDZHc9kiFbqEk8UOw@mail.gmail.com> <874m6ryz0u.fsf@yhuang-mobile.sh.intel.com> <CA+55aFzdnCDcf8nVtMTX7XiEoZVUqFahVA7kdns5aGKBWFqn3Q@mail.gmail.com> <20160811200018.GA28271@lst.de> <87ziojxazw.fsf@yhuang-mobile.sh.intel.com> <CA+55aFx=mbAd0hEnji-TWZH_NReLLk+SbJHK1s+=r1_USV0KXw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFx=mbAd0hEnji-TWZH_NReLLk+SbJHK1s+=r1_USV0KXw@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

I'll need to dig into what AIM7 actually does in this benchmark, which
isn't too easy as I'm on a business trip currently, but from the list
below it looks like it keeps overwriting and overwriting a file that's
already been allocated.  This is a pretty stupid workload, but fortunately
it should also be able to be optimized by skipping the actual block
lookup, which is what the old buffer.c code happens to do.