Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754541AbbGPPJJ (ORCPT ); Thu, 16 Jul 2015 11:09:09 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:33327 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752319AbbGPPJH (ORCPT ); Thu, 16 Jul 2015 11:09:07 -0400 Message-ID: <55A7C910.9040708@kernel.dk> Date: Thu, 16 Jul 2015 09:09:04 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ming Lei CC: Linux Kernel Mailing List , Mike Snitzer , Tejun Heo Subject: Re: [PATCH 0/4] block: account io: kill atomic operations References: <1437016607-375-1-git-send-email-tom.leiming@gmail.com> <55A7C449.4030406@kernel.dk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1663 Lines: 49 On 07/16/2015 09:01 AM, Ming Lei wrote: > On Thu, Jul 16, 2015 at 10:48 PM, Jens Axboe wrote: >> On 07/15/2015 09:16 PM, Ming Lei wrote: >>> >>> Hi, >>> >>> This patches kills two kinds of atomic operations in block >>> accounting I/O. >>> >>> The 1st two patches convert atomic refcount of partition >>> into percpu refcount. >>> >>> The 2nd two patches converts partition->in_flight[] into percpu >>> variable. >>> >>> With this change, ~15% throughput improvement can be observed >>> when running fio(randread) over null blk in a dual-socket >>> environment. >> >> >> I've played with this before, but always ran into the hurdle of making >> part_in_flight() too expensive ended up hurting results in the end. Making > > Yes, it is a bit expensive, but it is only run at most one time per tick for > one partition. Yup, but that can still be 1000 per second. And up until last year, it was even worse: 7276d02e241dc. So it's not too surprising if there's more low hanging fruit :-) If we can make the rounding more lazy, then we should go ahead and do that. >> the inc/dec parts of accounting percpu is a no-brainer, unfortunately the >> summing then becomes pretty expensive. I'll run this through some testing >> and see what kind of results I get. > > The first two patches should be fine, and it still can get ~8% improvement > in my test. Agree, those can go right in. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/