lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200608041746.59729.a1426z@gawab.com>
Date:	Fri, 4 Aug 2006 17:46:59 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] [3/3] Add the Elevator I/O scheduler

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ