[Lcdproc] LCDd 0.5.1 eating almost alll CPU on Debian Etch

[Peter Marschall]

Hi,

On Thursday, 1. March 2007 02:42, Stefan Herdler wrote:
> Mattia Jona-Lasinio wrote:
> > I'm the maintainer of the LCD-Linux project which is a kernel driver
> > for the
> > HD44780 controller connected to the parallel port.
> > I experience the same problem as you report here: programs using
> > LCD-Linux eat a
> > lot of cpu time. This happened since I moved to a distribution with a
> > 2.6 Linux
> > kernel. With the 2.4 kernel the cpu load was almost unreadable.
>
> My experiences had been quiet similar. On my kernel 2.4 (HZ 1000) system
> everything was working with moderate CPU usage while users with 2.6
> kernel have been reporting massive problems.
>
> > Therefore I don't think it is a matter of busy waiting loops but rather a
> > problem of HZ value in the kernel as Stefan suggested.
>
> Changing the Hz value I was able to switch between the 2 extremes,
> High CPU-load and fast refreshing and low CPU-load and unusable slow (1
> char/sec) refresh.
> I was using the predefined timing_uPause() function compiled to use
> nanosleep().
> It looks like nanosleep() switches between sleep- and busy-loop-timing,
> but I haven't found helpful informations about that.

Glancing at the code I also saw that DELAY_NANOSLEEP
changes to round robin scheduling.
Maybe this is the culprit.

> So I decided to use port-I/O-timing reading the BUSY-line of the display.
> It isn't the the most effective way, I think, but it seems to work
> reliable with moderate CPU-load on all tested systems.

Do you use the DELAY_IOCALLS method or using another mech ?
In case of the latter: how ?


> I recently took a look into the conf-file of  Graph-LCD
> <http://developer.berlios.de/project/showfiles.php?group_id=356>, they
> recommend to use timing with "gettimeofday" for the 2.6 kernels.
> Perhaps it helps.
> ** <http://dict.leo.org/ende?lp=ende&p=/gQPU.&search=recommend>

The gettimeofday thing looks quite like a busy-loop timing.
I had suggested this would cause more load than the sleep timing that 
nanosleep does. 

FWIW the busy-loop timing in the DELAY_NANOSLEEP only happens when 
an interrupt occurs. If that happens, nanosleep is set up
to sleep the remaining time and called again.

> > Can someone try
> > a kernel
> > compiled with the old 100 Hz value? Most kernels included in
> > distributions are
> > compiled with a HZ value of 1000 to take advantage of the new 2.6 Linux
> > scheduler and to have a finer grained time for processes.
>
> I currently don't have a running HD44780 display, sorry.
Me neither.

> > My tests are done on an Athlon 2800+ CPU with 1Gb of RAM. I think this
> > is quite
> > a fast machine to handle LCD stuff.

-- 
Peter Marschall
peter@adpm.de