From 8bfb6b40d75b67e3b5a471869dc86cc02fb0fb86 Mon Sep 17 00:00:00 2001 From: Vladislav Bolkhovitin Date: Thu, 7 Jul 2011 19:52:17 +0000 Subject: [PATCH] Web updates git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@3660 d57e44dd-8a1f-0410-8b47-8ef2f437770f --- www/contributing.html | 150 ------------------------------------------ 1 file changed, 150 deletions(-) diff --git a/www/contributing.html b/www/contributing.html index 56422fd87..83aad1f83 100644 --- a/www/contributing.html +++ b/www/contributing.html @@ -93,156 +93,6 @@ page cache, namely, locking issues related to it. They should be carefully investigated.

-

Dynamic I/O flow control

- -

At the moment, if an initiator or several initiators simultaneously send to - target too many commands, especially in seek intensive workloads, target can get - overloaded and not able to finish commands on time. In such cases you can see on - the initiator(s) messages about aborting commands or resetting the target. See in SCST core - README section "What if target's backstorage is too slow" for more details. - To fix this problem it is necessary to implement a dynamic I/O flow control in - SCST core.

- -

The flow control, generally, is quite simple. Each SCST command has timeout value, - which is set by the corresponding dev handler. SCST core should keep device's queue depth - at the level that the worst command's execution time, i.e. time between scst_rx_cmd() - and scst_finish_cmd(), would be between something like timeout/10 and timeout/5. - So, commands execution time should be checked and:

- - - -

The above is, of course, an oversimplification to let you see the idea. - Implementation considering real life cases should be as the following:

- -

1. There are several parameters:

- - - -

The default values should be something like: P=15 sec., MN=20, MX=10, Q=3, - I=1, D=2, QI=5 sec., QD=10.

- -

2. There are the following new variables in struct scst_device:

- - - -

3. The commands processing path should be as the following:

- - - -

4. There should be a work, which once in a P seconds will check - dev->max_exec_ratio, then:

- - - -

Then the flow control period is reset, i.e. started again, including - setting dev->max_exec_ratio to 0 and dev->quick_fall_time to jiffies.

- -

That's all. Then only support for initiators, like iSCSI, - which don't handle QUEUE FULL to decrease amount of queued - commands, should be added. Such initiators expect target to control size of - the queue, via, e.g., through MAX_SN for iSCSI.

- -

For it at the stage 2 of the dynamic flow control development - the following should be done:

- - - -

Then, at the latest stage of the development, logic to not schedule the - flow control work on idle devices should be added.

-

Support for O_DIRECT in scst_vdisk handler

At the moment, scst_vdisk handler doesn't support O_DIRECT option and possibility to set it