All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Jens Axboe <axboe@suse.de>, Andrew Morton <akpm@digeo.com>,
	Marc-Christian Petersen <m.c.p@wolk-project.de>,
	linux-kernel@vger.kernel.org, Con Kolivas <conman@kolivas.net>
Subject: Re: [PATCH] 2.4.20-rmap15a
Date: Mon, 2 Dec 2002 21:45:09 +0100	[thread overview]
Message-ID: <20021202204509.GA21070@alpha.home.local> (raw)
In-Reply-To: <Pine.LNX.4.44L.0212021035130.15981-100000@imladris.surriel.com>

On Mon, Dec 02, 2002 at 10:38:40AM -0200, Rik van Riel wrote:
> OK, do you have a better idea on how to implement this thing ?

Hello !

Please excuse my ignorance of the internals, but from a neutral view, I think
that an efficient design could be like this :
  - not one, but two elevators, one for read requests, one for write requests.
  - may be one couple of these elevators for each physical device to ease
    parallelism, but I'm not sure.
  - we would process one of the request queues (either reads or writes), and
    after a user-settable amount of requests processed, we would switch to the
    other one if it contains pending requests. For each request processed, we
    would take a look at the other queue, to see if a request for a very close
    location exists, in which case we would also switch.

This would bring the advantage of the latency/throughput balance being
completely user-settable.

Please excuse me if it's impossible in the current design or if it's already
done this way and fails. I just wanted to add my 2 euro-cents here.

Comments ?

Cheers,
Willy


  reply	other threads:[~2002-12-02 20:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-01 20:56 [PATCH] 2.4.20-rmap15a Marc-Christian Petersen
2002-12-01 21:25 ` Rik van Riel
2002-12-01 21:41   ` Marc-Christian Petersen
2002-12-01 21:56     ` Con Kolivas
2002-12-02  0:18     ` Con Kolivas
2002-12-02  8:15   ` Jens Axboe
2002-12-02  8:51     ` Andrew Morton
2002-12-02  8:56       ` Jens Axboe
2002-12-02 12:38         ` Rik van Riel
2002-12-02 20:45           ` Willy Tarreau [this message]
2002-12-02 23:10             ` Rik van Riel
2002-12-03  6:21               ` Willy Tarreau
2002-12-02 21:46           ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2002-12-01 20:35 Rik van Riel
2002-12-01 20:35 ` Rik van Riel
2002-12-03 13:55 ` Miquel van Smoorenburg
2002-12-03 16:39 ` Sean Neakums
2002-12-03 19:58   ` The One True Dave Barry
2002-12-03 20:08     ` Martin J. Bligh
2002-12-03 20:56       ` Rik van Riel
2002-12-04 11:28         ` Sean Neakums
2002-12-04 13:33           ` Sean Neakums
2002-12-04 11:40         ` Arjan van de Ven
2002-12-04 12:12           ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021202204509.GA21070@alpha.home.local \
    --to=willy@w.ods.org \
    --cc=akpm@digeo.com \
    --cc=axboe@suse.de \
    --cc=conman@kolivas.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.c.p@wolk-project.de \
    --cc=riel@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.