BIOS Polling - fixed it!

["Evan Langlois" <ekl@sdf.saomai.org>]

OK, I REALLY hate it when a program just sits an polls for IO, but many
applications have no choice, being written before the invention of threads
or Fselect() on the Atari.  But, MiNT doesn't handle this well.  Nearly
every other OS I know of, can "sense" when an app is polling - by how often
it checks for IO.  If it checks a certain number of times within a certain
time limit - then the application is given a very low priority so the polling
won't slow down the system.

I don't know how to program such an algorythm efficiently in just a few
hours, so here is what I DID do.  I used 3 programs.  One is a typical
terminal that uses while() loops around Bconstat() - it also counts
the number of times it calls Bconstat() - and reports it once per second using
Talarm (BTW, why does Talarm's argument the number of SECONDS?  Shouldn't
it be the number of milliseconds like the ATC says?).  The second program
is a PD fax program which I rarely have running because its polling eats up
so much CPU time.  Plus a simple bench-marker, which does little IO, but uses
alot of CPU time.

Now, having the bench and the terminal running at once gave each about 45-50%
CPU time.  Which at first, sounds about right, until you consider that one
is polling - doing nothing in an idle loop, making the bench alot slower!
Having data go through the terminal did not change how much it polled, nor
its priority. This is BAD!

I then edited bios.c (how do I make a diff for one file?  I forgot the options
to generate the format that is prefered by the mint-list).  Now, if the
Bconstat() or Bcostat() call reports no data waiting, the process is punished
with a lower priority.  If data is waiting - the apps priority is reset, in
case a burst of data is coming through it will get the slices it needs.

Now, polling apps still use 90+% CPU time, but they give up that time very
easily.  Having the terminal and the bench running at once means a 30/70
distribution of time (only 20-30% of the CPU is used by the polling app, not
50%).  Instead of polling 500 times a second, it does so about 300 times
a second.  Running the PD rcvfax program (which seems to use BIOS polling)
along with the tester resulted in a CPU usage of, again, 20-30% when the
rcvfax was idle, but it jumped to 66% when recieving a fax!!  Dropping
the CPU hog benchmark from 60+% down to about 20-30%!  This is the way
I think it should work, don't you?  Of course, the extra code i added 
does cause a small slow slowdown in the Bconstat() and Bcostat() calls,
but I don't see this as a problem - I never got a single error in my
23 page high-speed FAX document (on a 16Mhz STe, 14.4Fax, port @ 19.2K).
This was WITH the benchmark app running and doing random calculations.

So .. please sned me the command line for teh patch - or simply add it
for me (I ripped most of the punish/reward code from proc.c) and remind
me to send the patch if no one else does.  I think this is worth it.
It would be nice to do the same for AES apps that get alot of timer events.
Punish for lots of timer events, and reward for other events.  Eh?
Maybe?   

Thanks,
Evan Langlois