From mboxrd@z Thu Jan 1 00:00:00 1970 From: Werner Almesberger Subject: elevator priorities vs. full request queues Date: Tue, 22 Jun 2004 01:25:02 -0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622012502.B1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from almesberger.net ([63.105.73.238]:19721 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id S266578AbUFVEZH (ORCPT ); Tue, 22 Jun 2004 00:25:07 -0400 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id i5M4P8423583 for ; Mon, 21 Jun 2004 21:25:09 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id i5M4P2Q24502 for linux-fsdevel@vger.kernel.org; Tue, 22 Jun 2004 01:25:02 -0300 To: linux-fsdevel@vger.kernel.org Content-Disposition: inline List-Id: linux-fsdevel.vger.kernel.org Another issue regarding priorities: let's suppose we have "high" and "low" priority requests. Those priorities are indicated by some means, and do not depend on CPU scheduler priorities. Let's say that the elevator always handles high priority requests first, unless barriers dictate it to do otherwise. So far so good. Next, let's suppose that the request queue is filling up. Now all the processes doing IO will compete for request slots, and the outcome of this competition is determined by the CPU scheduler - which is blissfully unaware of those request priorities. Has anybody thought of a solution for this problem ? I can think of a few possible approaches, but they're all relatively intrusive or plain ugly. A few of them: 1) temporarily raise the CPU priority of processes waiting for request queue slots 2) implement some priority scheme in ll_rw_blk.c 3) give elv_may_queue more information about what the request will look like, so that it can decide to accept "high" priority requests even if the queue is officially full 4) allow elv_add_request to refuse requests, e.g. to keep some reserve for "high" priority requests 1) and 2) would have the advantage that they also work if requests are delayed due to a lack of memory. However, in this case, all bets are off anyway, so I wouldn't worry too much about it. 3) and 4) have the nice property of keeping all the priority logic entirely in the elevator. For 4), one would also have to force an interface change (besides giving elv_add_request a return value), to make sure there are no enqueuers left in the kernel or elsewhere which don't know that elv_add_request may now fail. Opinions ? - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/