From mboxrd@z Thu Jan 1 00:00:00 1970 From: Werner Almesberger Subject: Re: elevator priorities vs. full request queues Date: Tue, 22 Jun 2004 05:26:44 -0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622052644.D1325@almesberger.net> References: <20040622012502.B1325@almesberger.net> <20040622074852.GW12881@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from almesberger.net ([63.105.73.238]:11274 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id S261206AbUFVI0u (ORCPT ); Tue, 22 Jun 2004 04:26:50 -0400 To: Jens Axboe Content-Disposition: inline In-Reply-To: <20040622074852.GW12881@suse.de>; from axboe@suse.de on Tue, Jun 22, 2004 at 09:48:52AM +0200 List-Id: linux-fsdevel.vger.kernel.org Jens Axboe wrote: > Well yes, different parties have worked on io priorities in the past. > Request allocation is a important part of that. I only found your "cfq + io priorities" posting from November 2003. Are there any others that are publicly available ? > #4 doesn't work for various reasons, the obvious being that the request > is already allocated at this point. The idea would be to refuse/delay low-priority requests before reaching the queue limit. But yes, having a possibly large number of allocated but not enqueuable requests sit around, or being forced to discard requests after building them, may not be so great. > CFQ with priorities used a combination of 2+3. It seems you haven't > looked any of this up, maybe that would be a good starting point. I had to have a second look :-) I didn't quite realize that your changes actually solved that. Nice and simple. Are there any newer versions of it ? What are your plans for IO priorities anyway ? > CFQ used per-process (-group) priorities, In my case, they're per open file or per memory page. The latter works as follows: pages are explicitly prefetched at the application's declared read rate. When doing this, the prefetcher sets the page's priority, which the elevator retrieves. Sound complicated but actually doesn't cause all that much overhead. As a welcome side-effect, prefetching also limits the high-priority IO activity an application can generate. > A bio has room for priority info, so you could also pass it in > from submit_bio() -> __make_request() -> get_request() -> may_queue(). Hmm yes, that's the large set of little changes I was hoping to avoid. But I guess there's no way around this. Thanks, - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/