Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755018Ab1CGSUe (ORCPT ); Mon, 7 Mar 2011 13:20:34 -0500 Received: from smtp-out.google.com ([216.239.44.51]:24040 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753859Ab1CGSUd (ORCPT ); Mon, 7 Mar 2011 13:20:33 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iH2RS+rlKhvfaE6hy2yAcCzYIEVA9hENNsXuVwhjB9X35EtIoIXvp14w637U4Bye57 qefnEYCviAQpCKa7b0KA== MIME-Version: 1.0 In-Reply-To: <4D6F0ED0.80804@kernel.dk> References: <20110301142002.GB25699@redhat.com> <4D6F0ED0.80804@kernel.dk> From: Justin TerAvest Date: Mon, 7 Mar 2011 10:20:10 -0800 Message-ID: Subject: Re: RFC: default group_isolation to 1, remove option To: Jens Axboe Cc: Vivek Goyal , Chad Talbott , Nauman Rafique , Divyesh Shah , lkml , Gui Jianfeng , Corrado Zoccolo Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1893 Lines: 47 On Wed, Mar 2, 2011 at 7:45 PM, Jens Axboe wrote: > On 2011-03-01 09:20, Vivek Goyal wrote: >> I think creating per group request pool will complicate the >> implementation further. (we have done that once in the past). Jens >> once mentioned that he liked number of requests per iocontext limit >> better than overall queue limit. So if we implement per iocontext >> limit, it will get rid of need of doing anything extra for group >> infrastructure. >> >> Jens, do you think per iocontext per queue limit on request >> descriptors make sense and we can get rid of per queue overall limit? > > Since we practically don't need a limit anymore to begin with (or so is > the theory), then yes we can move to per-ioc limits instead and get rid > of that queue state. We'd have to hold on to the ioc for the duration of > the IO explicitly from the request then. > > I primarily like that implementation since it means we can make the IO > completion lockless, at least on the block layer side. We still have > state to complete in the schedulers that require that, but it's a good > step at least. So, the primary advantage of using per-ioc limits that we can make IO completions lockless? I'm concerned that looking up the correct iocontext for a page will be more complicated, and require more storage (than a css_id, anyway). I think Vivek mentioned this too. I don't understand what the advantage is of offering isolation between iocontexts within a cgroup; if the user wanted isolation, shouldn't they just create multiple cgroups? It seems like per-cgroup limits would work as well. Thanks, Justin > > -- > 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/