Re: Fix for slow process output processing (please test).

[storm@cua.dk (Kim F. Storm)]

David.Kastrup@t-online.de (David Kastrup) writes:

> > David Kastrup and others have reported very slow processing of process
> > output, particularly with the Linux kernel's scheduler giving emacs
> > too much attention while starving the processing producing the output.
> > 
> > Below is a patch which introduces a small delay on reading output from
> > such processes, without using global delays in processing other events
> > (this is done by temporarily removing the process' file descriptor from
> > the call to select and use a short timeout on the select instead.
> 
> I have glanced over that patch.  There is one problem I see with it:
> if indeed the generating process is able to produce lots of data with
> a single write call, Emacs will be throttling its input without a
> purpose.

With the patch, emacs only throttles if it reads less than 1024 bytes
at a time from the process -- i.e. if the process is unable to produce
data fast enough to fill emacs's read buffer.

So if you have a process which manages to write a lot of data in one
write, emacs should happily read that data with no throttling.

Of course, if it has just read some (slower) data with throttling, the
first few 1024 packages will still be trottled (max 100ms total), but
then it would read the rest at full speed.

> 
> This situation is quite more probable when we have a multiprocessor
> machine or when the input is generated by some network process (so
> again, on a different CPU).

If you have a multi-processor system, and your process generates
output at a steady (fast) stream, emacs will not do throttling on that
process.  Only if that process slows down, you will see throttling --
but how would you notice that?

And network traffic is not throttled by this patch!

> 
> The best behavior would be
> a) don't bother reading from the pipe for a while if it is not yet
>    full.
> b) process it immediately once it is completely full.

c) or process it after some timeout if there is any data in the pipe

Yes, there are various ways to accomplish this, but I would rather try
to find a simple solution which works reasonably well in most/all
cases, rather than a more complex (and perhaps o/s specific) solution
that I'm not really sure will work much better in general.

> 
> The select call does not offer any possibility to say "wake up
> immediately if there is such an amount of data".  And we need the
> select call to poll other input, so we can't just use blocking I/O
> with a timeout set (which would probably be the best solution if we
> had only to worry about a single source of input).
> 
> `Enterprise level' solutions would probably be:
> a) use blocking I/O with a timeout set in a separate thread.  When
> the timeout hits or the read completes, whatever has accumulated in
> the corresponding input buffer is marked for processing and made
> available to the main Emacs.
> b) use aio_read to request a full pipe worth of data.  If no signal
> announces the availability of the data, some timeout may be used to
> cancel the aio_read if there is data available, but not a full pipe
> worth of it.
> 
> Of course, those solutions are more operating system specific than the
> current one.  It may well be that there are few applications that will
> turn out worse by throttling Emacs to something like 8kB/20ms or so.
> 

We may go for more advanced solutions, if the current patch does not
solve the problem (maybe with some tuning of the throttling
parameters).

But I would like some feedback on the effects of the current patch
first (also on multi-processor systems if possible); maybe it just
happens to be "good enough" in practice.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk