Priorities not only for CPU but also for HD, Network and oth

[richie]

Hi!

Are there any clever solutions how the OS can allow the user to set different priorities for different processes? Normally you can set the CPU priority. In the past this was a cool idea since CPU power was a limiting factor. But nowadays there are more limited resources like harddisk or network bandwidth. CPU time can be split up in small time slices and a process with higher priority would get more time slices than one with low priority. But although the high priority process will have more CPU time the low priority process will not stuck and can do his work (of course slower). But spliting up harddisk access in small time slices would be unsatisfactory because the head movements will slow down both processes. On the other hand if you have one process in the background that does a lot of disk access (e.g. decompress a huge file) and another process in the foreground that does only rare disk access (e.g. reading linked text documents) it would be perfect if the foreground process could do his job without being disturbed by the background process (which of course will be slown down). So for disk access there might be the priorities: "service at once" and "background".

You can think over every device this way (e.g. harddisk, network, CD-ROM). Not only every kind of device but every single device could have its own priorities. e.g. one process should get "service at once" for Disk A but not for Disk B. This all would make priorities very difficult. Not only for the OS developer but also the user. Would do you think about this idea? Are there other suggestions how to face this problem? I have no concret question but I'm interested in your opinions, ideas and suggestions.

Thanks for any comment

[Therx]

I'm not sure how you'd go about it but couldn't you make it so that there's the sequence. Task1 is doing diskaccess and Task2 isn't

TASK1 sends command to disk
TASK2
TASK1 recieves status and sends next command
TASK2

Remember that just because the hardwares working the software can do other things. The difficulty with this is making sure that the status back goes to the correct process and that the process accessing the disk is run again soon enough that the disk doesn't timeout. How about a disk server task and to access the disk you send a message to it. Then you only have one task doing diskaccess. When its finished it sends a message back.

Sorry about the mess of ideas but I typed them aas I thought of them. The trouble is that either method requires alot of supporting features to be implemented first.

Pete

[kaos]

Disk access schedulers present some interesting problems. Obviously, access for things like reading virtual memory from disk for high priority processes should have high priority. There are some complexities though, ex: should IO-bound tasks have lower priority for disk access? I tend to think that the answer is no and that they should probably even have higher priority for disk access, but this might not be true in all cases.

When scheduling disk access operations, should operations that are on positions between the current position on the drive and the position of the highest priority operation be scheduled before the highest priority operation? This could improve overall performance while degrading the QoS of the high priority operation. How can we answer this question? Is there a better approach?

[Pype.Clicker]

Everywhere there's a wait queue, there should be the ability to plug a scheduler, and everytime a scheduler can improve the workload, there should be a scheduler running.

For network resource, there are existing solutions (QoS) that will allow to fair-share your bandwidth among a set of 'flows'. Being able to classify packets into flows is usually based on the IP and port address.
If your applications can use the "Type Of Service" tag of IP packets it sends to the NIC, it becomes even easier.

For disk access there is indeed more challenge. You have to cope with
- background operations (as mentionned earlier), but not completely prevent them from working fine
- interactive operations (like reading a directory for browsing, etc)
- memory swapping (would we give priority of swap-out operations that free some memory)
- system maintainance: things like inode update or journal commits can suffer no delays and must be performed on time while file writes may be cached and deferred.

Now, i admit that if i could force my VMware not to consume more than 50% of disk access, it would be pretty useful :-p

[Solar]

This is definitely one of those priority-related things that should not be given into the hands of the user. It's much to easy to muck up your whole system just by setting priorities wrongly. This should be handled internally by the OS.

That being said, the whole shebang depends heavily on your overall OS structure. One keyword probably is "priority inheritance". Reading up on realtime scheduling could also be helpful, since those texts usually also touch the topic of I/O scheduling.

Even more, it also depends on your overall access structure. Do you optimize your HD access for head movement efficiency? If so, that adds another factor to the equation.

You cannot handle this topic in a generic, one-size-fits-all way. But yes, a sophisticated I/O scheduling would surely benefit overall performance.

(But don't fall into the trap of considering the CPU no longer being a limited resource. Everything is limited, and should be handled as such.)

[Pype.Clicker]

This is definitely one of those priority-related things that should not be given into the hands of the user. It's much to easy to muck up your whole system just by setting priorities wrongly.

That certainly applies to Joe Average, Mr. Anykey, Mrs Typeright and the like, but Sarah Programatzi and Miss Maxframe will love to tune the relative priority of their tasks.

There should probably be several kind of rules:

• those that are set up by the system. e.g. journal commits *must* be performed in order and *must* act as a barrier for the scheduler (that is, anything submitted in the queues after a journal commit should be performed after that commid. period.)
• those that are defined by the user and that apply to that user's request only (for instance, using a tool like top for disk access you could be able to say "limit disk request to N/seconds for Kazaa" or "keep 10% of disk access time for interactive process", etc).
• those that are defined by the system administrator and that apply among users, like "ensure fair sharing of disk access time accross users".

Imho, optimizing the disk requests is performed by advancing some late requests in the queue to improve the overall efficience. By limitting 'how much' a given request may advance, you can trade off queue time for workload, and by blocking some request before they reach the scheduler, you can tradeoff workload for fairness.

Still a draft in my mind, though ...

[Solar]

I disagree with the notion that every "switch" in the system should be reachable by the user, or even by the one building the OS binaries. I think some things are perfectly good if researched, decided, and hardcoded by the OS designer, but that's a matter of personal taste.

[kaos]

I'm thinking that disk requests of priority within ranges of a specified size (we'll call it sigma) should be scheduled to minimize movement on the disk. It pops the first request from the stack and sets the low value of the range (omicron) equal to the priority. It checks the next priority on the stack to see if it is greater than omicron+sigma. If it is, the scheduler stops popping. Otherwise it continues popping until before it finds a priority greater than omicron+sigma. At this point, the scheduler sorts the popped requests into ascending or descending order by location, depending on the the current location of the disk cursor. They are then served in that order, and the process is repeated. If a request of priority is made within the range of priorities currently being served and is after the current location of the disk cursor, it should be inserted into the list of requests that are being served. If it is below that range, it should be enqueued. If it is above that range, the range should be redefined, and those previously scheduled requests that fall outside the range should be enqueued. Somebody has probably thought of this before.

How do you like this idea?

[Pype.Clicker]

How do you like this idea?

Hmm ... i'll probably have to convert it to pseudocode before i can express anything about it ... but i don't have time to do so by now