Skip to contentSkip to conversation

staircase scheduler v6.4 for 2.6.7-rc3

PATCH In review Con Kolivas 3 participants 4 messages Jun 8, 2004

lore
Share & tools
lore

Con Kolivas

author
#0 lore raw

PATCH 1/1 staircase scheduler v6.4 for 2.6.7-rc3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is an updated full version of the staircase scheduler (not attached for brevity of email):

http://ck.kolivas.org/patches/2.6/2.6.7-rc3/patch-2.6.7-rc3-s6.4

25 files changed, 264 insertions(+), 545 deletions(-)

Changes:
Tiny bugfixes, cleanups.
Slight tweak to tasks waiting on I/O
Massive cleanups from wli - thanks!

Comments, testing welcome
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxcvsZUg7+tp6mRURAgZFAJ4/iTCfBF/AotI70tbjPgW3xPy2TACggYgS 38J+HdFXv0lThCUzx07kNhM=
=eO0E
-----END PGP SIGNATURE-----

#1 lore raw
Quoted 8 lines · Con Kolivas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is an updated full version of the staircase scheduler (not attached for brevity of email):

http://ck.kolivas.org/patches/2.6/2.6.7-rc3/patch-2.6.7-rc3-s6.4

25 files changed, 264 insertions(+), 545 deletions(-)

There was no need to add the extra overhead of a flag to indicate that a task was queued for scheduling. Testing whether run_list is empty achieves the same thing as reliably as the old array == NULL test did.

Signature · 4 lines
Dr Peter Williams                                [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
#2 lore raw
Quoted 3 lines · Peter Williams

There was no need to add the extra overhead of a flag to indicate that a task was queued for scheduling. Testing whether run_list is empty achieves the same thing as reliably as the old array == NULL test did.

Overhead? Doubtful. Also, that requires the use of list_del_init() while dequeueing, which is not in place now. Please do back the claim with measurements. It should be easy enough to nop out set_task_queued(), implement task_queued() via !list_empty(), and clear_task_queued() via INIT_LIST_HEAD() for a quick performance comparison. But I'd say to merge it even if there's no difference, as it's more self-contained.

-- wli

#3 lore raw
Quoted 6 lines · William Lee Irwin III
Quoted 1 line · Peter Williams

There was no need to add the extra overhead of a flag to indicate that a task was queued for scheduling. Testing whether run_list is empty achieves the same thing as reliably as the old array == NULL test did.

Overhead? Doubtful. Also, that requires the use of list_del_init()

Yes, that's true.

Quoted 6 lines

while dequeueing, which is not in place now. Please do back the claim with measurements. It should be easy enough to nop out set_task_queued(), implement task_queued() via !list_empty(), and clear_task_queued() via INIT_LIST_HEAD() for a quick performance comparison. But I'd say to merge it even if there's no difference, as it's more self-contained.

Since the principle use of testing array for NULL or not was to find out if the task was on a run list it seems silly to have a flag to determine this. All it does is provide an opportunity for the flag to not accurately reflect whether the task is really on a list or not.

It caused the number of files touched by the staircase patch to increase
by a factor of five which is another good reason to use the alternative.

Peter

Signature · 4 lines
Dr Peter Williams                                [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce