From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751993Ab3FEDDp (ORCPT ); Tue, 4 Jun 2013 23:03:45 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:57232 "EHLO mail-pd0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750971Ab3FEDDk (ORCPT ); Tue, 4 Jun 2013 23:03:40 -0400 Date: Tue, 4 Jun 2013 20:03:37 -0700 From: Tejun Heo To: Robin Dong Cc: linux-kernel@vger.kernel.org, Zhu Yanhai , Vivek Goyal , Jens Axboe , Tao Ma , kent.overstreet@gmail.com Subject: Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device Message-ID: <20130605030337.GO14916@htj.dyndns.org> References: <1370398171-25173-1-git-send-email-sanbai@taobao.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1370398171-25173-1-git-send-email-sanbai@taobao.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 (cc'ing Kent. Original posting at http://thread.gmane.org/gmane.linux.kernel/1502484 ) Hello, On Wed, Jun 05, 2013 at 10:09:31AM +0800, Robin Dong wrote: > We want to use blkio.cgroup on high-speed device (like fusionio) for our mysql clusters. > After testing different io-scheduler, we found that cfq is too slow and deadline can't run on cgroup. > So we developed a new io-scheduler: tpps (Tiny Parallel Proportion Scheduler).It dispatch requests > only by using their individual weight and total weight (proportion) therefore it's simply and efficient. > > Test case: fusionio card, 4 cgroups, iodepth-512 So, while I understand the intention behind it, I'm not sure a separate io-sched for this is what we want. Kent and Jens have been thinking about this lately so they'll probably chime in. From my POV, I see a few largish issues. * It has to be scalable with relatively large scale SMP / NUMA configurations. It better integrate with blk-mq support currently being brewed. * It definitely has to support hierarchy. Nothing which doesn't support full hierarchy can be added to cgroup at this point. * We already have separate implementations in blk-throtl and cfq-iosched. Maybe it's too late and too different for cfq-iosched given that it's primarily targeted at disks, but I wonder whether we can make blk-throtl generic and scalable enough to cover all other use cases. Thanks. -- tejun