Re: Debian vs kernel.org kernel -- pty performance
Just a brief followup...
On Fri, Nov 20, 2009 at 04:19:42PM +1100, Robert Swan wrote:
> Today I posted a question to the kernelnewbies forum
> (http://forum.kernelnewbies.org/read.php?9,1122), but perhaps it would
> have been smarter to ask my question here.
I was quite wrong. There was no Debian specific change that avoided
the problem; it was a problem introduced in July between
2.6.31-rc2-00205-gb4b21ca and 2.6.31-rc2-00206-gd945cb9. And the
problem remains in the latest development kernel too.
It appears to be related to changes Alan Cox was making when he and
Linus Torvalds had a falling out.
Anyhow, as you were. I'll head back to the general Linux kernel
hackers with my problem.
Have fun,
Rob.
> The standard Debian kernel is fast and my own custom built kernel is
> slow for a program I have been developing. Here is a cut'n'paste of
> my postings linked above:
>
> Posting #1
> ! I have been using custom compiled kernels for years, but have hit a
> ! problem with my kernel that isn't there if I use a standard Debian
> ! kernel.
> !
> ! Two C programs are having a query-response conversation through a
> ! pseudo terminal:
> !
> ! A (client) -- forever { send query; read response }
> ! B (server) -- forever { read query; send response }
> !
> ! Neither has any I/O apart from the pty conversation, so I'd expect to
> ! see CPU usage at 100%. When I ran it, the CPU was pretty well idle.
> ! After a fair bit of fiddling, it turned out that both sides were
> ! taking about 8ms for their read() calls. At that point it seemed
> ! pretty clear that this was a delay in the kernel, not the code.
> !
> ! In a rare moment of inspiration, I downloaded Debian's latest kernel
> ! (my custom one is 2.6.31.5; I think the Debian one was 2.6.26.x, but I
> ! don't think that's too relevant) and booted with it. Now 100% CPU
> ! usage, and the program running vastly quicker. Good...
> !
> ! I've compared my .config with Debian's. Vastly different (no great
> ! surprise), and I've turned a few slightly promising options on or off
> ! to match. But the resulting kernel still has this delay.
> !
> ! Can anyone suggest where this "hold the buffer for 8ms" behaviour
> ! might be hidden?
> !
> ! I have stripped down example programs if anyone wants to investigate.
>
> Posting #2
> ! One more point...
> !
> ! I have just built a (huge) kernel from the kernel.org sources using
> ! the debian .config. The pty test is still slow. Evidently there is
> ! some tweak that the Debian people do to the source. I struck something
> ! similar a few years ago with tmpfs slowing down over time with
> ! standard sources, but not with RedHat.
> !
> ! I guess I'll download the Debian sources and see what their changelog
> ! has to say. Anyone got an easier way?
>
> As you can see, I have now thought of an easier way: ask here.
>
> Does a problem with unnecessary delays in scheduling of terminal based
> programs ring a bell with anybody?
>
> Happy to provide the sample programs if that is of interest.
>
> Have fun,
>
> Rob.
--
Robert Swan | No, not the antarctic adventurer.
swan.r.l@gmail.com | No, not the Canberra porn monger.
| Yes, that's right, the boring one.
Reply to: