> > The interactive session tends to be somewhat worse, but the command
> > line version is bad enough for a demonstration.
>
> this is within emacs:
>
> 1 blocks with size 95
> 1 blocks with size 146
> 1 blocks with size 175
[...]
> 1 blocks with size 980
> 2 blocks with size 987
> 1 blocks with size 991
> 1 blocks with size 998
> 1 blocks with size 1023
> 8 blocks with size 1024
>
> from the shell prompt:
>
[...]
Wel, those are excellent results and as it should be.
> my emacs is:
>
> GNU Emacs 21.2.1
Same here.
I am talking about the kernel coming with RedHat 9, uname -a gives
Linux lola.goethe.zz 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
Unfortunately, this kernel is here to stay for quite a while, and I
would want to find a way to let Emacs cooperate with it better without
telling people to recompile the kernel or wait a year.
> > Again, I am pretty sure that Emacs is at fault too, but I don't
> > understand the implications of what scheduling behavior causes the
> > pipes to remain mostly empty, with an occasional full filling. It
> > would be better if Emacs would not be context-switched into the
> > moment something appears in the pipe, but if the writer to the
> > pipe would keep the opportunity to fill'er'up until it is either
> > preempted or needs to wait. If there was some possibility to
> > force this behavior from within Emacs, this would be good to know.
>
> I don't see any slowdown here.
Which kernel? Oh, and of course: on a SMP machine the problem would
not be visible since then the context switch to Emacs does not stop
the other process from stuffing into the pipe.
Taking notice, but will need some time to apply. And I really would
want to find a way to avoid triggering this problem.
-- David Kastrup, Kriemhildstr. 15, 44793 Bochum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/