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

[Stefan Herdler]

Hi,
Peter Marschall wrote:
>> 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.
>   
It is listed as bug in the manpage of nanosleep() i found here:  
<http://www.tin.org/bin/man.cgi?section=2&topic=nanosleep>http://www.tin.org/bin/man.cgi?section=2&topic=nanosleep 
<http://www.tin.org/bin/man.cgi?section=2&topic=nanosleep>
That would explain why I had no problems on my system.
>   
>> 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 ?
>   
I do not use the DELAY_IOCALLS method but my implementation does pretty 
much the same.
> In case of the latter: how ?
>   
I'm reading the status-register of the parallel port until the display 
isn't busy any more.
Every port read takes about 1ms. Actually it is nothing else then a 
busy-loop.
>   
>> 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.
>>     
>
> The gettimeofday thing looks quite like a busy-loop timing. 
I'm quiet sure it is.
> I had suggested this would cause more load than the sleep timing that 
> nanosleep does.
Not necessarily it depend on on the time to sleep and the scheduler 
settings.
On my system there was no nameable difference between nanosleep() and 
port-IO (the time to wait I tested was about10...30ms).
I guess setting the scheduling to round robin (with realtime-priority?) 
causes nanosleep() staying in a busy-loop.

However my knowledge is only collected from manpages and the internet.  
That's my first contact with this kind of timing in Linux.

Stefan