Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752717AbYAXNsY (ORCPT ); Thu, 24 Jan 2008 08:48:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751610AbYAXNsP (ORCPT ); Thu, 24 Jan 2008 08:48:15 -0500 Received: from as3.cineca.com ([130.186.84.211]:50963 "EHLO as3.cineca.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbYAXNsO (ORCPT ); Thu, 24 Jan 2008 08:48:14 -0500 Message-ID: <47989711.3070708@users.sourceforge.net> From: Andrea Righi Reply-To: righiandr@users.sourceforge.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070604 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Pavel Emelyanov Cc: Naveen Gupta , Jens Axboe , Paul Menage , Dhaval Giani , LKML , Balbir Singh Subject: Re: [PATCH] cgroup: limit block I/O bandwidth References: <4791DC2C.9090405@users.sourceforge.net> <4793507B.6040706@users.sourceforge.net> <20080120143239.GS6258@kernel.dk> <47936BC1.9060805@users.sourceforge.net> <20080120160651.GU6258@kernel.dk> <4793E047.1000602@users.sourceforge.net> <2846be6b0801221102y2ad297e2u2f9df06e33b72162@mail.gmail.com> <47967805.4060307@users.sourceforge.net> <2846be6b0801221717j41984f93v920d271b948d39be@mail.gmail.com> <47975C0F.3010609@users.sourceforge.net> <20080123153828.GB12333@balbir.in.ibm.com> <4797A9C3.1000707@users.sourceforge.net> <479854E7.5080404@openvz.org> In-Reply-To: <479854E7.5080404@openvz.org> X-Enigmail-Version: 0.95.0 OpenPGP: id=77CEF397; url=keyserver.veridis.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: Thu, 24 Jan 2008 14:48:01 +0100 (MET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1747 Lines: 42 Pavel Emelyanov wrote: > Andrea Righi wrote: >> Balbir Singh wrote: >>> * Andrea Righi [2008-01-23 16:23:59]: >>> >>>> Probably tracking who dirtied the pages would be the best approach, but >>>> we want also to reduce the overhead of this tracking. So, we should find >>>> a smart way to track which cgroup dirtied the pages and then only when >>>> the i/o scheduler dispatches the write requests of those pages, account >>>> the i/o operations to the opportune cgroup. In this way throttling could >>>> be done probably in __set_page_dirty() as well. >>>> >>> I think the OpenVZ controller works that way. >> Well... looking at the code it seems that OpenVZ doesn't use this >> strategy, instead performs UBC-based I/O accounting looking at the > > We do track the task (well - the beancounter) who made the page > dirty and then use this context for async write scheduling. Interesting... now I see that task_io_account_write() takes a "struct page *" as argument and the "struct page" has the beancounter pointer. > >> __set_page_dirty*() for writes and submit_bio() for reads. Then, >> independently from accounting data, it uses per-UBC i/o priority model >> that is mapped directly on the CFQ i/o priority model. > > Vasisly Tarasov (out I/O guru ;)) has already prepared an RFC patchset > for Jens with group scheduler (for sync requests only) and is going to > send it this or next week. > Very good! I look forward for this patchset. Thanks, -Andrea -- 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/