Вести с полей

From

Slawa Olhovchenkov (2:5030/500)

To

All

Date

2007-01-11T02:59:26Z

Area

RU.UNIX.BSD

Hello All!

From: lulf@stud.ntnu.no
Subject: Pluggable Disk Schedulers in GEOM

Hi,

I was wondering if someone have started on the pluggable
disk-scheduler project
on the "new ideas"-page yet.

I was thinking on how one could implement this in GEOM by creating a
lightweight
scheduler API/Framework integrated in GEOM. The framework would be in
charge of
changing which schedulers that are to be used by the g_up and g_down threads.

I've put down some design goals for this:
1. Little/no overhead in I/O processing with default scheduling
compared to the "old" way.
2. Easily modifiable, preferable on-the-fly switching of schedulers.
3. Make it possible to many different schedulers to be implemented, without
  creating a too alien interface too them, but at the same time not restrict
  them too much.

More specifically my plan was to change the
g_up_procbody/g_down_procbody to ask the scheduler
framework on which scheduler to use, and then further implement
procedures in that
framework to handle the details of loading, switching and unloading
different schedulers
for I/O. Then I would extract out the default I/O scheduler and try out some
other ways to schedule I/O. Also, I'm not sure how I would handle each
schedulers way to organize the queue. One should allow for different types
of bioq's for the schedulers since they may have different needs of
organizing
queues (like a heap maybe).

I've started with some of my tampering in a p4 branch lulf_gpds. I have a
DESCRIPTION document that would maybe explain some of my thoughts and
problems
further. Some small code are written, but I want to hear some others
thoughts on this before I go crashing around doing stuff I might hate
later I did :)

I was also thinking of an alternative way to implement this like a
"gpds"-layer that could provide different schedulers to service I/O requests,
because that would make it to fine-grain more on scheduling, say telling that
the system-drive is used in a characteristic way and that one specific
scheduler algorithm is more
appropriate there, and another drive is having a different
characteristic which then should use a different algorithm.
However, this should be doable directly in geom as previously described, but
with a bit more tampering with other code. This is probably the most
efficient
way since it has no overhead of another GEOM class.

I also have some questions about the GEOM layer in itself. Does the
VM-manager
actually swap pages out to disk via GEOM, or does it do that by itself (which
would make more sense in terms of efficiency).

I'd like to hear from some of the GEOM gurus' view on this.
Is the something that sounds doable and worth spending time on?
Is there something I've overlooked? Have I completely lost my mind?
I sometimes have the ability to write a bit different than what my mind is
thinking sometimes :)

Anyway, I'd like to research a bit on this topic to just see how much
it does matter with different I/O scheduling for different purposes.

Comments are welcomed!


... Что бы различать оттенки дерьма надо быть гурманом.
--- GoldED+/BSD 1.1.5
 * Origin:  (2:5030/500)
SEEN-BY: 50/12 203 400/814 450/186 1024 451/30 469/418 550/196 4614/20 4635/4
SEEN-BY: 5000/5000 5011/13 5012/46 5015/28 5019/26 5020/154 175 400 545 549
SEEN-BY: 5020/758 1523 1604 1630 2142 2238 2395 2450 2590 2871 4441 5021/3 29
SEEN-BY: 5022/128 5025/3 750 5027/12 5029/32 5030/500 556 966 1900 1957 2828
SEEN-BY: 5031/47 70 5035/38 5040/47 5042/13 5045/7 5049/50 97 5054/1 4 8 9 11
SEEN-BY: 5054/28 35 36 37 45 66 67 70 75 84 85 5059/9 37 5062/1 10 5063/3
SEEN-BY: 5064/7 5076/1 5077/70 5080/80 1003 5082/6 5083/21 5084/9 5085/13
SEEN-BY: 5090/108 5094/4 5095/20 5096/18 5099/11 6001/10

PATH: 5030/500 5020/4441 545 5054/1 37