mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Boldi <a1426z@gawab.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] [3/3] Add the Elevator I/O scheduler
Date: Fri, 4 Aug 2006 17:46:59 +0300	[thread overview]
Message-ID: <200608041746.59729.a1426z@gawab.com> (raw)

Nate Diller wrote:
> This is the Elevator I/O scheduler.  It is a simple one-way elevator,

Thanks for yet another attempt to achieve an efficient 2.6 elevator.

> +static inline char contig_char(struct el_request *e)

You probably meant el_req.  Check the rest.

> +static void print_queue(struct request_queue *q, struct el_data *el)
> +{
> +       struct el_req *e;
> +
> +       printel(el);

Should be print_el_data.

Applied against 2.6.17, it boots with this:
	io scheduler elevator registered (default)
	elevator: forced dispatching is broken (nr_sorted=13), please report this

> +In pure form its largest weakness is starvation of other processes due to
> +one process writing a very large number of contiguous requests (e.g.
> +tarring a very large tar file while other processes are trying to run).

cat /dev/hda > /dev/null starves the rest of the system.

> +The max_contig and max_write tunables are two (imperfect) solutions. They
> +
> +These two tunables are still under construction, but they have proven
> +somewhat useful in practice.  Usually, max_contig should be the same size
> +(in bytes) as ra_pages.

It's 0 by default.  Setting it to ra_pages prints this:
	nate 1977: max_contig went backwards

> +
> +  SSTF
> +
> +The SSTF feature was added on a whim.  It ignores the tunables, and
> probably +breaks tracing.  I didn't ever see it perform better than SCAN,
> but who +knows?

Starves too.


Thanks!

--
Al


             reply	other threads:[~2006-08-04 14:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-04 14:46 Al Boldi [this message]
2006-08-04 18:17 ` Nate Diller
  -- strict thread matches above, loose matches on Subject: below --
2006-08-04  2:21 Nate Diller
2006-08-04  5:17 ` Andrew Morton

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=200608041746.59729.a1426z@gawab.com \
    --to=a1426z@gawab.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome