Re: The cron problem and a solution

[jfm2@club-internet.fr]

> 
> > 
> > Nicing a job is not enough.  Suppose the job is IO intensive (like
> > makewhatis) and the user is doing something IO intensive.  The user
> > task gets priority and issues an IO request.  The CPU is now free so
> > makewhatis is allowed to run and will issue an IO request.  Both jobs
> > will be very slow because the disk heads will be constantly moving
> > from where the foreground job is reading to where the makewhatis is
> > rezading.  So the best solution is trying to avoiding starting the
> > cron job until there is no other activity.
> 
> That is going to happen regardless.  Imagine that the system looks at the load
> and sees that it is low and kicks off a process to rebuild the man database.
> Just then, the user attempts to do something but the system is performace is
> poor because of the process that started just BEFORE the user tried to do
> something.  
> 

The problem is there is _NO_ ideal scheme (that is the reason I want
to keep the traditional way for servers).  We can just try to not
interfere when we know the user is making heavy use of the machine.
If we get it first it will be to him to wait a bit until we end our
task.  He is a human and he will catch that.

> What I am getting at is that looking at the current load might not mean
> anything because we can not predict what demands will be placed on the system
> in the immediate future. Also, system load is not a reliable indicator of I/O
> activity. A rather I/O intensive procedure may not result in a high load level.
> The load level as displayed in the uptime command is only number of processes
> waiting for CPU service averaged over time. A very I/O intensive process may
> not result in a high load level with a bus-mastering SCSI controller and a
> system with a small number of total processes running. On the other hand, a
> process can use significant CPU time with relatively little I/O activity.
> 
> Trying to guess when the user will not be using the system is difficult. My
> suggestion is to perform these processes in such a way as to interfere as
> little as possible (some interference is going to be required and must be
> tolerated) with the completion of interactive user processes.
> 

That is what I mean.  I attract your attention than "batch" nices its
jobs and in _addition_ it tries to not start them when the load is high.
That is better than a scheme based only on niceness.
Batch will not start a job if the execution date is not reached.


Of course we could make a more sophisticated check than the one made
by batch and account for IO load.  The problem is than the Linux
kernel does not convey that information AFAIK.

Like I said there is no perfect scheme.  We have to design one not too
bad and issue it to people who cannot use traditional schemes.

About tasks at shutdown: Shutdown must take no longer than one minute.
People can be tired and wanting to go to bed, or they can have a plane
to catch, or be willing to play a DOS game.  If it takes long they
will be angry.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================