Linux

I read somewhere that low pri can actually run faster/cheaper because the slice is larger, or something such. I find the SA's go nuts if you use it all nice -19, even though it works on fine. Appearance of impropriety.

On an idle machine quite possibly, though it sounds heavily implementation-specific and application-specific too. Big timeslices matter for CPU bound things.

On a loaded system, a nice -19'd process will get barely any time, politely behaving or not. That's not a bug or anything the scheduler can fix, that's simply the system doing what you told it to.

Unless everything else is 19'ed too, of course.

I agree that priority can be used intelligently, but think it should be up to the sysadmin to raise priorities above average. Leaving it up to the users can cause problems. Leaving it up to the sysadmin can cause problems too, but at least there's just one of them

Paging i/o being an exception -- favoring that can create thrashing. I accidentally found I could severely slow a system using mmap() to map a file and then read the data, for a long list of files in succession (an mmap() based fgrep). Memory was full of old mapped page images, and everyone else was on swap. There should be some limit on how many pages of ram one pid can have 'originated', something like 80%, so you can use ram for speed, but not so you roll everyon else out, maybe invoked when too may processes are awaiting page in. Many OS now use mmap() for input buffering of data flat files -- no buffer needed.

For a system to be very responsive to priority, you need prioritized queues for i/o that reach out into the peripherals and networks, and that raises a lot of issues off-host. With all the buffering, NFS, remote printers, SANs and such, things tend to get democratic and ballistic early on in the flow. Getting the CPU first is not enough to keep the low guys from filling the queue with requests.

Emotionally, people think a system runs faster when everyone has more priority! LOL!

Yes, and severe swap is particularly nasty in that it can steal time from high-priority things indirectly. Stealing their memory now, means stealing their time later -- they'll go for their data and get a context switch instead. If you're burning a CD, that can mean coasters. Dealing with this in the OS itself is difficult since it adds so much overhead to each page operation though.

Linux supports voluntary measures for cache control, though. You can use madvise to tell the kernel you're done with a page, and so avoid cluttering up the cache with it.

I thought CD burners, the new ones, have enough buffer to survive o/s and app underflow. I guess it depends on how long a track is, or whether the firmware.CD hardware/medaia allows it to see where it left off and turn on writing right there.

The mmap()/munmap() is neat, though, as it allows a 32 bit program to use unlimited RAM. Things mapped stay in memory even if unmapped and are available to a new map, so you can swap super-pages of a huge set of files in your limited address space. Of course, mmap64() allows you to leave it all mapped, at the cost of fatter code. Some sort of client-server arrangement allows tight 32 bit clients to access all that data on a tight 64 bit data server.

16 megs of buffer vs 600 megs of data, worst case there's never enough. Modern buffer underrun protection isn't quite that perfect, it leaves little recoverable errors on the disk. I don't think a CDR/DVDR has the angular resolution to turn on the laser right spot-on where it left off, so I think it leaves little markers for itself when it must. It can survive brief underruns, brief being the key. Interesting idea.

Well, infrequent -- once you underrun and it writes a glitch-gap, you have all the time in the world to get back to writing, presumably after buffers are full again, but too many times on one CD/DVD and the bandwidth and capacity are impacted. It might be more forgiving on data CDs, since they are internally segmented. If a music CD is full 600 MB with 12 tracks, the average track is 50 MB, so 16 megs is a good percentage. Classical music albumns might have very few, larger tracks compared to rockNroll, like 11:30 for Beethoven's 2nd Symphony in D Major, Movement 2 Larghetto = 100 MB.