doubts about disk scheduling - Linux

This is a discussion on doubts about disk scheduling - Linux ; I would appreciate any help on the following questions. I have looked on disk scheduling algorithms and the main thing that striked me is that most of the algorithms that i have read in the textbooks (some are explained in ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 33

Thread: doubts about disk scheduling

  1. doubts about disk scheduling

    I would appreciate any help on the following questions.

    I have looked on disk scheduling algorithms

    and the main thing that striked me is that most of the algorithms that
    i have read in the textbooks (some are explained in the previous )
    don't take into consideration the "priority of the process". Being the
    short seek time first, scan, or c-scan algorithm, all are explained
    through a string of block numbers, but no mention is given about the
    owner of these blocks.does it mean all the processes are treated
    equally?? In my opinion a sort of Multi level queue like with CPU
    scheduling algorithm can be used to schedule the processes according to
    their importance. any comment?


    My second question is about the implementation, i.e. how the different
    requests are actually aligned in the disk queue?

    if a process submit a disk I/O request, its PCB should be linked to the
    disk queue. My question is, in making the system call, and after
    checking the permission rights and identifying the sought data (block)
    address in the disk and the target address in the memory does the
    kernel store this information in the pcb, then link this pcb in the
    disk queue?

    By doing so and once the disk controller is free , the device driver
    checks the queue pcbs and read the requested blocks and depending on
    the current location of the disk head and the queue pcb block request,
    the driver orders the controller to process a certain block request of
    a certain process. The driver removes this request from the pcb content


    is that how it is implemented?

    Many thanks


  2. Re: doubts about disk scheduling

    xu_feng_xu@yahoo.com wrote:
    > I would appreciate any help on the following questions.
    >
    > I have looked on disk scheduling algorithms
    >
    > and the main thing that striked me is that most of the algorithms that
    > i have read in the textbooks (some are explained in the previous )
    > don't take into consideration the "priority of the process". Being the
    > short seek time first, scan, or c-scan algorithm, all are explained
    > through a string of block numbers, but no mention is given about the
    > owner of these blocks.does it mean all the processes are treated
    > equally?? In my opinion a sort of Multi level queue like with CPU
    > scheduling algorithm can be used to schedule the processes according
    > to their importance. any comment?


    So far this has been largely overlooked or ignored. The I/O priority should
    also be there. I want to be able to build my project (which is taking hours)
    and at the same time be able to read e-mails or work in an editor, but the
    constant disk activity from the build is making that other work hardly
    possible. And what's worst, there doesn't seem to be a way to set up the
    priority to a tree of processes, which you have if you're building something
    complex and run make, perl, compiler, linker and other things at different
    times throughout the build. In part this is easied by keeping the project on
    a different disk from the rest of the stuff. That's what I see on Windows
    XP.

    Vista seems to be better in this respect, but I haven't had enough time to
    play with it yet.

    Google for "Vista I/O priority" for more info.

    Alex


  3. Re: doubts about disk scheduling

    > i have read in the textbooks (some are explained in the previous )
    > don't take into consideration the "priority of the process".


    Correct. Windows, for instance, ignored the thread dispatcher priority of the
    disk IO originator for years. There are rumours it is not so in Vista, but I'm
    not sure of it.

    > if a process submit a disk I/O request, its PCB should be linked to the
    > disk queue.


    In Windows, not so.

    2 separate objects are created - IRP which describes the IO operation and MDL
    which describes the memory area over which the IO operation must run. Then the
    IRP is linked to the storage port driver's queue.

    The hardware queue of the storage target is also used - if the target has it.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com


  4. Re: doubts about disk scheduling

    "Alexei A. Frounze" writes:
    > xu_feng_xu@yahoo.com wrote:
    >> I would appreciate any help on the following questions.
    >> I have looked on disk scheduling algorithms
    >>
    >> and the main thing that striked me is that most of the algorithms that
    >> i have read in the textbooks (some are explained in the previous )
    >> don't take into consideration the "priority of the process". Being the
    >> short seek time first, scan, or c-scan algorithm, all are explained
    >> through a string of block numbers, but no mention is given about the
    >> owner of these blocks.does it mean all the processes are treated
    >> equally?? In my opinion a sort of Multi level queue like with CPU
    >> scheduling algorithm can be used to schedule the processes according
    >> to their importance. any comment?

    >
    > So far this has been largely overlooked or ignored.


    It doesn't really matter: Most disk read requests should be serviced
    from the page cache (if not, you don't have enough memory) and write
    requests should simply go into a kernel buffer and the kernel will
    asynchronously forward them to the disk, ideally ordered for a large
    througput and interleaved in a sensible way with read requests which
    could not be serviced from the page cache.

    > I want to be able to build my project (which is taking hours) and at
    > the same time be able to read e-mails or work in an editor, but the
    > constant disk activity from the build is making that other work
    > hardly possible.


    That is certainly too little main memory.

    > And what's worst, there doesn't seem to be a way to set up the
    > priority to a tree of processes, which you have if you're building
    > something complex and run make, perl, compiler, linker and other
    > things at different times throughout the build.


    Consider reading an entry-level text of dynamic scheduling priorities
    on UNIX(*) or Linux.

  5. Re: doubts about disk scheduling

    Rainer Weikusat wrote:
    > "Alexei A. Frounze" writes:
    >> xu_feng_xu@yahoo.com wrote:
    >>> I would appreciate any help on the following questions.
    >>> I have looked on disk scheduling algorithms
    >>>
    >>> and the main thing that striked me is that most of the algorithms
    >>> that i have read in the textbooks (some are explained in the
    >>> previous ) don't take into consideration the "priority of the
    >>> process". Being the short seek time first, scan, or c-scan
    >>> algorithm, all are explained through a string of block numbers, but
    >>> no mention is given about the owner of these blocks.does it mean
    >>> all the processes are treated equally?? In my opinion a sort of
    >>> Multi level queue like with CPU scheduling algorithm can be used to
    >>> schedule the processes according to their importance. any comment?

    >>
    >> So far this has been largely overlooked or ignored.

    >
    > It doesn't really matter: Most disk read requests should be serviced
    > from the page cache (if not, you don't have enough memory) and write
    > requests should simply go into a kernel buffer and the kernel will
    > asynchronously forward them to the disk, ideally ordered for a large
    > througput and interleaved in a sensible way with read requests which
    > could not be serviced from the page cache.
    >
    >> I want to be able to build my project (which is taking hours) and at
    >> the same time be able to read e-mails or work in an editor, but the
    >> constant disk activity from the build is making that other work
    >> hardly possible.

    >
    > That is certainly too little main memory.


    That's how you look at it. Seriously, if we had unlimited resources (not
    2 GBs in my case, but um... 2 flavors * 4 GBs in each (that's only the
    produced objects and binaries) + whatever the source takes plus some cushion
    for the tools, libraries they're using, etc ... 16 GB of RAM???), we
    wouldn't run into these problems, right? But I'm not sure it's something
    people generally do -- spend on each developer's main machine extra 1.5
    grands just for the RAM to make the build smooth and fast and bearable when
    trying to do something else at the same time when the stuff is building. And
    there're apparently dozens to a hundred of developers in this big project...
    And the funny thing is that it would probably be cheaper to get another
    low-end computer for the e-mail and source code editing than to try to fix
    the problem by putting lots of RAM into a single PC, which brings us back to
    the point that if there was some scheme for prioritization or something to
    reserve and guarantee the resources for the more interactive processes, the
    same machine with the same amount of RAM would be just right.

    >> And what's worst, there doesn't seem to be a way to set up the
    >> priority to a tree of processes, which you have if you're building
    >> something complex and run make, perl, compiler, linker and other
    >> things at different times throughout the build.

    >
    > Consider reading an entry-level text of dynamic scheduling priorities
    > on UNIX(*) or Linux.


    That'll not fix the problem that I described above that's happening on
    Windows XP, will it?

    Alex


  6. Re: doubts about disk scheduling

    "Alexei A. Frounze" writes:
    > Rainer Weikusat wrote:


    [...]

    >>> I want to be able to build my project (which is taking hours) and at
    >>> the same time be able to read e-mails or work in an editor, but the
    >>> constant disk activity from the build is making that other work
    >>> hardly possible.

    >>
    >> That is certainly too little main memory.

    >
    > That's how you look at it.


    No, that is not 'how I look at it'. If you have interactive jobs that
    are disk bound for long enough to be 'hardly usable', your working set
    obviously does not fit into RAM and then you need more memory, a
    faster disk or bus or a smaller working set if you want this to
    improve.

  7. Re: doubts about disk scheduling

    Rainer Weikusat wrote:
    > "Alexei A. Frounze" writes:
    >> Rainer Weikusat wrote:

    >
    > [...]
    >
    >>>> I want to be able to build my project (which is taking hours) and
    >>>> at the same time be able to read e-mails or work in an editor, but
    >>>> the constant disk activity from the build is making that other work
    >>>> hardly possible.
    >>>
    >>> That is certainly too little main memory.

    >>
    >> That's how you look at it.

    >
    > No, that is not 'how I look at it'. If you have interactive jobs that
    > are disk bound for long enough to be 'hardly usable', your working set
    > obviously does not fit into RAM and then you need more memory, a
    > faster disk or bus or a smaller working set if you want this to
    > improve.


    To me it sounds like trying to excuse or defend the design that doesn't make
    much of a difference between the two processes from the interactive
    standpoint (or take a hint from outside) and fix the problem quantitatively,
    not qualitatively. Surely, that's not something impossible. Just doesn't
    seem quite right. That's my thinking.

    Alex


  8. Re: doubts about disk scheduling

    Alexei A. Frounze wrote:
    > Rainer Weikusat wrote:
    >> "Alexei A. Frounze" writes:
    >>> Rainer Weikusat wrote:

    >>
    >> [...]
    >>
    >>>>> I want to be able to build my project (which is taking hours) and
    >>>>> at the same time be able to read e-mails or work in an editor, but
    >>>>> the constant disk activity from the build is making that other work
    >>>>> hardly possible.
    >>>>
    >>>> That is certainly too little main memory.
    >>>
    >>> That's how you look at it.

    >>
    >> No, that is not 'how I look at it'. If you have interactive jobs that
    >> are disk bound for long enough to be 'hardly usable', your working set
    >> obviously does not fit into RAM and then you need more memory, a
    >> faster disk or bus or a smaller working set if you want this to
    >> improve.

    >
    > To me it sounds like trying to excuse or defend the design that doesn't
    > make much of a difference between the two processes from the interactive
    > standpoint (or take a hint from outside) and fix the problem
    > quantitatively, not qualitatively. Surely, that's not something
    > impossible. Just doesn't seem quite right. That's my thinking.
    >

    Then your thinking is wrong.

    The disk is used because there is no room left in RAM to cache stuff.

    More ram or a faster disk are the only options.

    Or a machine dedicated to 'building', alone...

    Compiling and linking large projects involves a lot of file activity -
    think about it - all the included files have to be opened and read, and
    combined with the sources..then the compiler probably makes a few passes
    over the resultant heap of wombat turds, discarding everything
    irrelevant, doing a fair amount of computation, building intermedaiate
    files, maybe asm files and then finally spitting out an object
    file..then all those have to be ground together with whatever static
    libraries are involved, each one of which has to be searched and the
    relevant object modules extracted and bound with the final objects..
    CPU and disk is all there.

    The only way you can hope to reduce disk IO is by having the entirety of
    all those files in RAM somewhere...and maybe defragging a fairly full
    disk..sadly the size of files these days and the number of object files
    generally means that at some point you will run out.

    Maybe there are kernel tuneables you can tweak to assign more ram to
    disk IO, but these days its cheaper to simply stuff the machine full,
    and/or get a second machine..doesn't need a screen, or much more than a
    basic development install and an ethernet card..we learnt from bitter
    experience that mixing compile and link engines with anything else lead
    to howls of protest from everyone else using the same servers..the
    answer was dedicated 'sandpits' in which teh techies could play while th
    rest of te company merrily used the dedicated file and print servers and
    reserved their lower spec desktop machines for chatting to each other by
    e-mail, and occasionally doing some work...





    > Alex
    >


  9. Re: doubts about disk scheduling

    On Tue, 12 Dec 2006 22:35:29 +1100, The Natural Philosopher wrote:

    > Alexei A. Frounze wrote:
    >> To me it sounds like trying to excuse or defend the design that
    >> doesn't make much of a difference between the two processes from the
    >> interactive standpoint (or take a hint from outside) and fix the
    >> problem quantitatively, not qualitatively. Surely, that's not something
    >> impossible. Just doesn't seem quite right. That's my thinking.
    >>

    > Then your thinking is wrong.


    Depends on the context. There's nothing wrong about musing "Couldn't we do
    something about this?" from an OS development perspective. Unfortunately
    the original poster posted to a few different groups, each with its own
    area of interest. It's unclear to me whether he (she?) wanted to know
    whether this functionality is supported in Linux or whether he could
    reasonably hope to implement it in his own OS.


    > Compiling and linking large projects involves a lot of file activity -
    > think about it - all the included files have to be opened and read, and


    I think Alex knows what's involved in compiling and linking. No real need
    for him to think about it.


    > The only way you can hope to reduce disk IO is by having the entirety of
    > all those files in RAM somewhere...and maybe defragging a fairly full
    > disk..


    That may be true, if reducing disk IO is the goal. But I thought the
    question was about aligning disk IO priorities to process priorities, so
    that a nominally high-priority foreground process (say, mail or Tetris)
    can genuinely and holistically have high priority even while a
    disk-intensive build is going on in the background. An interesting
    question... I'm very interested in hearing what people who know more about
    it than I do have to say.


    Cheers,
    Ciaran

    --
    Ciaran Keating
    Amadán Technologies Pty Ltd

  10. Re: doubts about disk scheduling

    Ciaran Keating wrote:

    >> The only way you can hope to reduce disk IO is by having the entirety
    >> of all those files in RAM somewhere...and maybe defragging a fairly
    >> full disk..

    >
    > That may be true, if reducing disk IO is the goal. But I thought the
    > question was about aligning disk IO priorities to process priorities, so
    > that a nominally high-priority foreground process (say, mail or Tetris)
    > can genuinely and holistically have high priority even while a
    > disk-intensive build is going on in the background. An interesting
    > question... I'm very interested in hearing what people who know more
    > about it than I do have to say.
    >

    What you have to deal with is that I imagine most disk scheduling algorithms
    for UNIX-like operating systems are set up to provide the highest overall
    throughput. Now if you tinker with that to improve the throughput of
    selected processes, or of selected files, the overall throughput of the
    system will go down.

    Now if this is a single-user system of the UNIX type (one that is inherently
    multi-user), it might suffice to set the processor priority of the
    "background process" sufficiently low (high nice number). But if you are
    running the system multi-user, you will reduce the overall throughput.

    So that is just not the way to go. Recall the old dictum: the more you try
    to outsmart an operating system, the more it will outsmart you.

    As a previous poster said, if doing a large build in the background, there
    are a huge number of files that must be opened and read besides the source
    program files themselves: header files (very large numbers because many
    header files include yet other header files), statically linked libraries,
    and even some IO for the dynamically linked libraries, etc. And, with enough
    RAM, it just might be that most of the headers in a Linux system might end
    up in the cache.

    So if disk IO is the problem at all (and it could very well be), getting
    additional hard drives and putting (in this case) the header files on one,
    the libraries on another, and leaving all the rest on an existing drive
    might be the way to go. I do not know if this would help much with IDE
    drives, but it should work quite well with SCSI drives. These extra drives
    would operate with their own queues and with their own queue servers. Disk
    drives are pretty cheap these days, and so is RAM compared with the early
    days when memory cost about $40/bit.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 07:50:01 up 52 days, 10:21, 4 users, load average: 4.04, 4.14, 4.16

  11. Re: doubts about disk scheduling

    On Wed, 13 Dec 2006 00:05:59 +1100, Jean-David Beyer
    wrote:

    > Ciaran Keating wrote:


    >> I'm very interested in hearing what people who know more
    >> about it than I do have to say.
    >>

    > What you have to deal with is that I imagine most disk scheduling
    > algorithms
    > for UNIX-like operating systems are set up to provide the highest overall
    > throughput. Now if you tinker with that to improve the throughput of
    > selected processes, or of selected files, the overall throughput of the
    > system will go down.


    Fair enough. Well, it's a fair comment, but maybe a reduction in overall
    throughput would be acceptable.


    > As a previous poster said, if doing a large build in the background,
    > there
    > are a huge number of files that must be opened and read


    > So if disk IO is the problem at all (and it could very well be), getting
    > additional hard drives and putting (in this case) the header files on
    > one,
    > the libraries on another, and leaving all the rest on an existing drive
    > might be the way to go.


    I suppose I didn't say... I meant I was curious about what might be done
    from an OS development point of view. As in, is it at all feasible to
    extend a process's scheduling priority to also define priority access to
    IO devices?



    --
    Ciaran Keating
    Amadán Technologies Pty Ltd

  12. Re: doubts about disk scheduling

    "Alexei A. Frounze" writes:
    > Rainer Weikusat wrote:
    >> "Alexei A. Frounze" writes:
    >>> Rainer Weikusat wrote:

    >> [...]
    >>
    >>>>> I want to be able to build my project (which is taking hours) and
    >>>>> at the same time be able to read e-mails or work in an editor, but
    >>>>> the constant disk activity from the build is making that other work
    >>>>> hardly possible.
    >>>>
    >>>> That is certainly too little main memory.
    >>>
    >>> That's how you look at it.

    >>
    >> No, that is not 'how I look at it'. If you have interactive jobs that
    >> are disk bound for long enough to be 'hardly usable', your working set
    >> obviously does not fit into RAM and then you need more memory, a
    >> faster disk or bus or a smaller working set if you want this to
    >> improve.

    >
    > To me it sounds like trying to excuse or defend the design that
    > doesn't make much of a difference between the two processes from the
    > interactive standpoint


    As you are clearly a person with no clue about the topic you are
    talking about, what something looks like to you isn't that important.


  13. Re: doubts about disk scheduling

    "Ciaran Keating" writes:
    > On Tue, 12 Dec 2006 22:35:29 +1100, The Natural Philosopher wrote:
    >> Alexei A. Frounze wrote:
    >>> To me it sounds like trying to excuse or defend the design that
    >>> doesn't make much of a difference between the two processes from
    >>> the interactive standpoint (or take a hint from outside) and fix
    >>> the problem quantitatively, not qualitatively. Surely, that's not
    >>> something impossible. Just doesn't seem quite right. That's my
    >>> thinking.
    >>>

    >> Then your thinking is wrong.

    >
    > Depends on the context. There's nothing wrong about musing "Couldn't
    > we do something about this?" from an OS development
    > perspective.


    Except that the problem the original poster was phantasizing about is
    imaginary (if not an outright fabrication). The only reason why an
    interactive job can possible be affected by disk activity of other
    tasks to the point of being 'hardly usuable' is when it is making
    heavy use of the system paging areas because it does not fit into
    memory together with all the other stuff running on the system. If you
    use more RAM than you have, eg have significant paging activity on the
    system, you either have to wait or put more RAM into the machine.


    [...]

    >> The only way you can hope to reduce disk IO is by having the
    >> entirety of all those files in RAM somewhere...and maybe defragging
    >> a fairly full disk..

    >
    > That may be true, if reducing disk IO is the goal.


    And because the disk is by far the slowest heavily used peripheral,
    increasing disk througput is the goal because the latency is always
    going to suck.

    That is not exaclty a current research problem.



  14. Re: doubts about disk scheduling

    Jean-David Beyer wrote:
    > [...] What you have to deal with is that I imagine most disk
    > scheduling algorithms for UNIX-like operating systems are set up to
    > provide the highest overall throughput. Now if you tinker with that
    > to improve the throughput of selected processes, or of selected
    > files, the overall throughput of the system will go down.
    >
    > Now if this is a single-user system of the UNIX type (one that is
    > inherently multi-user), it might suffice to set the processor
    > priority of the "background process" sufficiently low (high nice
    > number). But if you are running the system multi-user, you will
    > reduce the overall throughput.
    >
    > So that is just not the way to go. Recall the old dictum: the more
    > you try to outsmart an operating system, the more it will outsmart
    > you.


    ok... i'll give you another reason why i/o prioritization is important:

    1. setup your favourite unix-flavour
    2. you're the administrator of the machine and work with it as well
    3. now let me use the system
    i'll just start [x] processes, using up all memory
    i'm allowed to do. and each process tries to do as
    much i/o as possible:

    for(;
    {
    readRandomFile();
    writeRandomFile();
    }


    that'll give you a hard time working on the system.




    > So if disk IO is the problem at all (and it could very well be),
    > getting additional hard drives and putting (in this case) the header
    > files on one, the libraries on another, and leaving all the rest on
    > an existing drive might be the way to go.


    i/o prioritization is free. why buy a new harddrive when you can just
    install new software? you could argue against page files as well ("just
    buy more ram") with the same reasoning.



    regards,
    simon

    --

    http://valhalla.iru.ch/

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----

  15. Re: doubts about disk scheduling

    [FU set to comp.os.linux.development.system as the most appropriate, IMO]

    In <87hcw1b27o.fsf@farside.sncag.com> Rainer Weikusat:

    [Snip...]

    > That is not exaclty a current research problem.


    Exactly, nor is it really germane to many colm readers, who simply want to
    get a stable Linux install "working" (for certain values of "working"). So
    they'd rather not yawn through histories of interactive response arcana.

    IMO the OP is (1) trolling; or (2) stuck in some schoolwork. Go figure...

    JMO; YMMV...

    --
    Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
    Pardon any bogus email addresses (wookie) in place for spambots.
    Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
    Kids jumping ship? Looking to hire an old-school type? Email me.

  16. Re: doubts about disk scheduling

    In comp.os.linux.development.system Simon Felix wrote in part:
    > ok... i'll give you another reason why i/o prioritization is important:
    >
    > 1. setup your favourite unix-flavour
    > 2. you're the administrator of the machine and work with it as well
    > 3. now let me use the system
    > i'll just start [x] processes, using up all memory
    > i'm allowed to do. and each process tries to do as
    > much i/o as possible:
    >
    > for(;
    > {
    > readRandomFile();
    > writeRandomFile();
    > }
    >
    >
    > that'll give you a hard time working on the system.


    Mostly because many OSes prioritize swapping higher than
    regular disk-I/O. So swap VM requests break the elevator runs.

    In severe cases with broken OSes (MS-Windows), the system
    simply stops until swapping completes.

    Be careful with any IO prioritization that you don't break
    the elevators -- on a clear disk you can seek forever

    -- Robert


  17. Re: doubts about disk scheduling

    Ciaran Keating wrote:
    > On Wed, 13 Dec 2006 00:05:59 +1100, Jean-David Beyer
    > wrote:
    >
    >> Ciaran Keating wrote:

    >
    >>> I'm very interested in hearing what people who know more
    >>> about it than I do have to say.
    >>>

    >> What you have to deal with is that I imagine most disk scheduling
    >> algorithms
    >> for UNIX-like operating systems are set up to provide the highest overall
    >> throughput. Now if you tinker with that to improve the throughput of
    >> selected processes, or of selected files, the overall throughput of the
    >> system will go down.

    >
    > Fair enough. Well, it's a fair comment, but maybe a reduction in overall
    > throughput would be acceptable.
    >
    >
    >> As a previous poster said, if doing a large build in the background,
    >> there
    >> are a huge number of files that must be opened and read

    >
    >> So if disk IO is the problem at all (and it could very well be), getting
    >> additional hard drives and putting (in this case) the header files on
    >> one,
    >> the libraries on another, and leaving all the rest on an existing drive
    >> might be the way to go.

    >
    > I suppose I didn't say... I meant I was curious about what might be done
    > from an OS development point of view. As in, is it at all feasible to
    > extend a process's scheduling priority to also define priority access to
    > IO devices?
    >

    Sure. Anything is possible. But one person sitting at the only console on a
    Linux machine may get into a lot of non-repeatable hot water that would
    never carry over to a machine that is really multiprogramming and probably
    multiprocessing as well. We are really talking about feedback control
    systems and understanding these seems to have dropped out of formal
    engineering training starting in the early 1970s.
    >
    >
    > --Ciaran Keating
    > Amadán Technologies Pty Ltd



    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 15:20:01 up 52 days, 17:51, 3 users, load average: 4.37, 4.35, 4.23

  18. Re: doubts about disk scheduling

    On Wed, 13 Dec 2006 01:47:39 +1100, Rainer Weikusat
    wrote:

    > Except that the problem the original poster was phantasizing about is
    > imaginary (if not an outright fabrication).


    Over here in alt.os.development, fantasizing and using your imagination is
    allowed.


    > The only reason why an


    And we like to keep an open mind. I mean, we positively enjoy it.


    >> That may be true, if reducing disk IO is the goal.

    >
    > And because the disk is by far the slowest heavily used peripheral,
    > increasing disk througput is the goal


    Well, actually, the original question was: "I have looked on disk
    scheduling algorithms [...] and the main thing that striked me is that
    most of the algorithms [...] don't take into consideration the "priority
    of the process". [...] [D]oes it mean all the processes are treated
    equally?? In my opinion a sort of Multi level queue like with CPU
    scheduling algorithm can be used to schedule the processes according to
    their importance. any comment?"

    So it seems to me that overall disk throughput is not mentioned here.


    > That is not exaclty a current research problem.


    That's OK. We don't mind.


    Cheers,
    Ciaran

    --
    Ciaran Keating
    Amadán Technologies Pty Ltd

  19. Re: doubts about disk scheduling

    xu_feng_xu@yahoo.com wrote:
    > In my opinion a sort of Multi level queue like with CPU
    > scheduling algorithm can be used to schedule the processes according to
    > their importance.


    I have done this for a soft-real-time OS, sorting I/O requests by
    priority and (less significantly) by disk address (not attempting to
    model cylinder boundaries). In practice there may not be enough I/O
    requests at one time to benefit from sorting except for a flood of
    writes from the disk cache, which can be given the lowest priority.

    > if a process submit a disk I/O request, its PCB should be linked to the
    > disk queue.


    > My question is, in making the system call, and after
    > checking the permission rights and identifying the sought data (block)
    > address in the disk and the target address in the memory does the
    > kernel store this information in the pcb, then link this pcb in the
    > disk queue?


    The queue element would never be a PCB (process control block) as that
    would not permit multiple outstanding I/Os per process, and some I/O
    (such as cache flushing) may not even be associated with a process.

    The queue has to be made up of some kind of storage. Unix actually made
    a major step forward here by requiring the caller of a driver to provide
    a queue element. The predecessor OS Multics had a serious problem when
    a fixed-size queue became full, as the driver couldn't give up the CPU
    (deep in page fault handling) so could only spin-wait until the queue
    had a free element. The caller of the driver may have a better way to
    obtain a queue element, such as having one reserved for each page of
    memory.

    > By doing so and once the disk controller is free , the device driver
    > checks the queue pcbs and read the requested blocks and depending on
    > the current location of the disk head and the queue pcb block request,
    > the driver orders the controller to process a certain block request of
    > a certain process. The driver removes this request from the pcb content
    >
    > is that how it is implemented?


    Yes, except not using the PCB, and allowing for lots of complications
    (disk cache, discontiguous allocation of files, I/O errors, disks that
    can handle short queues internally). The queue element specifies what
    is to be done when the I/O completes. (This very much depends on the
    OS.) Typically a wakeup is sent that awakens the process that requested
    the I/O. If the caller owns the queue element then he can check the
    results of the I/O there (error, partial transfer, EOF, etc.) and reuse
    or deallocate the element.

  20. Re: doubts about disk scheduling

    Ciaran Keating wrote:
    > On Tue, 12 Dec 2006 22:35:29 +1100, The Natural Philosopher wrote:
    >> The only way you can hope to reduce disk IO is by having the entirety
    >> of all those files in RAM somewhere...and maybe defragging a fairly
    >> full disk..

    >
    > That may be true, if reducing disk IO is the goal. But I thought the
    > question was about aligning disk IO priorities to process priorities,
    > so that a nominally high-priority foreground process (say, mail or
    > Tetris) can genuinely and holistically have high priority even while a
    > disk-intensive build is going on in the background.


    I doubt that disk queue priority will help. The queue depth is limited
    by the number of active processes. If you're running multiple
    compilations in parallel, stop doing that or put up with the result.
    If there's just one, your foreground process read will only have to
    wait for one compiler read to complete, probably a single read for the
    whole file since you want that optimized. That read was already in
    progress when the foreground read entered the queue so would not have
    been stopped for any reasonable priority implementation.

    I suspect that Windows still doesn't know how to lower the priority
    of a background process, or doesn't know how to preempt it for
    responsiveness.

+ Reply to Thread
Page 1 of 2 1 2 LastLast