LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 11-14-2010, 03:53 PM   #1
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Rep: Reputation: 0
[slackware 13.1] xpdf very slow and cpu goes to 100%


A brief preamble:

I'm gonna tell you about slackware installation on my notebook, an acer travelmate 800lci.

On this notebook, I successfully installed (and work with) slackware from version 10.0 till the recent 13.0. Upgrading to a new version till using a new internal hard disk (from 40 GB to 160 GB). After upgrade I fully reinstall slackware 12.2 and then upgrade to 13.0.

Now, I had to use the notebook for testing, so I made a new full installation of slackware 13.0 and after some time a new full installation of slackware 13.1.
On this disk (160 GB P-ATA) I have to pass the following parameter to the kernel:
libata.ignore_hpa=1
during installation and boot.
This operation solve the issue that can "see" the full size of the disk (160 GB) and not the 137 GB limit.

--

Only using slackware 13.1, occur a big (for me) problem.
I can fully reproduce it opening any pdf document with xpdf: moving into document with arrow keys make the cpu goes to 100% and page "fault/s" goes from 30 to 8000 and some times 15000 "fault/s". So, xpdf becomes unusable. This problem reflects in similar manner to other software, like firefox.

Here is my question: what type of analisys could I try to solve/analyze this issue? Maybe the kernel, xorg, wtf ?

On slackware 13.0 all works perfectly.
 
Old 11-14-2010, 04:00 PM   #2
darkstarbyte
Member
 
Registered: May 2010
Location: 3 planets away from the sun.
Distribution: Linux mint, Slackware
Posts: 231

Rep: Reputation: 2
I heard of similar issues with this and the issue was something to do with the upgrade package.
 
Old 11-14-2010, 08:11 PM   #3
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,520
Blog Entries: 27

Rep: Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174Reputation: 1174
One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.
 
Old 11-15-2010, 12:52 AM   #4
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,322

Rep: Reputation: 353Reputation: 353Reputation: 353Reputation: 353
Quote:
Originally Posted by cacao74 View Post

Only using slackware 13.1, occur a big (for me) problem.
I can fully reproduce it opening any pdf document with xpdf: moving into document with arrow keys make the cpu goes to 100% and page "fault/s" goes from 30 to 8000 and some times 15000 "fault/s". So, xpdf becomes unusable. This problem reflects in similar manner to other software, like firefox.

Here is my question: what type of analisys could I try to solve/analyze this issue? Maybe the kernel, xorg, wtf ?

On slackware 13.0 all works perfectly.
I don't have any issues with xpdf under Slackware64 13.1, much less the one that you describe.

I do see it with xpdf under Slackware 13.1 (the 32bit version) on my other machine.

You could run top (or qps or system monitor) to see what exactly is spiking the CPU. It might be the X server.
 
Old 11-15-2010, 01:33 AM   #5
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by catkin View Post
One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.
You're right. I could use eVince (not installed), or okular (installed).
Okular works pretty well, but I am a xpdf lover.
;^)
 
Old 11-15-2010, 02:04 AM   #6
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Richard Cranium View Post
I don't have any issues with xpdf under Slackware64 13.1, much less the one that you describe.

I do see it with xpdf under Slackware 13.1 (the 32bit version) on my other machine.

You could run top (or qps or system monitor) to see what exactly is spiking the CPU. It might be the X server.
On slackware64, everything works very well. It's another pc, but the 64bit version is fantastic! No issues for me, now.

On 32 bit version, the problems exists only with the 13.1 of slackware.
I've initially run top when xpdf becomes slowly: top shows 100% of cpu usage related to xpdf process. After that I tried to find some indexes using iostat, vmstat, sar, ... and I founded something with "sar -B". That's why I've written in the initial post about high page fault per second.

To give an idea of the issue, here is some snippet from the shell when I use xpdf.
The file used for test is this:
Code:
[cacao74@tweety ~]$ man -t yes | ps2pdf - cacao.pdf
Open the file with xpdf
[code]
[cacao74@tweety ~]$ xpdf -z width -g 640x400 cacao.pdf &
[1] 3392
On other 2 xterm window, I trace top and sar output (filtered) that show some indexes of using xpdf. The highest value of cpu% usage (top) and fault/s (sar), are related to pressing arrow down key to scroll down the pdf document till the end of the page.

output of top:
Code:
[cacao74@tweety ~]$ top -p 3392 -b -n 20 -d 1 | grep "PID\|xpdf"
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13264 9044 3852 S  0.0  0.7   0:00.15 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13264 9044 3852 S  0.0  0.7   0:00.15 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13264 9044 3852 S  1.0  0.7   0:00.16 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13264 9044 3852 S  0.0  0.7   0:00.16 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S  8.0  0.7   0:00.24 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 8912 3852 R 57.8  0.7   0:00.82 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 R 84.8  0.7   0:01.67 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 7244 3852 R 89.8  0.6   0:02.57 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 R 87.8  0.7   0:03.45 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S 79.8  0.7   0:04.25 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S  0.0  0.7   0:04.25 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S  0.0  0.7   0:04.25 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S  0.0  0.7   0:04.25 xpdf               
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3392 cacao74   20   0 13368 9048 3852 S  0.0  0.7   0:04.25 xpdf
output of sar:
Code:
[cacao74@tweety ~]$ sar -B 1 20
Linux 2.6.33.4-smp (tweety)     15/11/2010      _i686_  (1 CPU)

08:54:38     pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
08:54:39         0,00      0,00     35,00      0,00    131,00      0,00      0,00      0,00      0,00
08:54:40         0,00      0,00     38,00      0,00     73,00      0,00      0,00      0,00      0,00
08:54:41         0,00      0,00    959,60      0,00   1510,10      0,00      0,00      0,00      0,00
08:54:42         0,00      0,00   4796,04      0,00   7770,30      0,00      0,00      0,00      0,00
08:54:43         0,00     44,00  10894,00      0,00  15914,00      0,00      0,00      0,00      0,00
08:54:44         0,00      0,00   9656,00      0,00  14695,00      0,00      0,00      0,00      0,00
08:54:45         0,00      0,00   9199,00      0,00  15472,00      0,00      0,00      0,00      0,00
08:54:46         0,00      0,00   9312,00      0,00  14670,00      0,00      0,00      0,00      0,00
08:54:47         0,00      0,00     32,00      0,00    319,00      0,00      0,00      0,00      0,00
08:54:48         0,00      0,00   2063,37      0,00    521,78      0,00      0,00      0,00      0,00
08:54:49         0,00      0,00     36,00      0,00     67,00      0,00      0,00      0,00      0,00
08:54:50         0,00      0,00     32,32      0,00     83,84      0,00      0,00      0,00      0,00
08:54:51         0,00      0,00     54,00      0,00    218,00      0,00      0,00      0,00      0,00
^C
I will continue to investigate. :^)

[edit]
just one note:
the heavy cpu usage is much more noticeable when viewing a "real" pdf file, such as a tecnical document, which freeze my xpdf experience and make the notebook fan start her noisy music...
[/edit]

Last edited by cacao74; 11-15-2010 at 02:11 AM. Reason: added some notes
 
Old 11-15-2010, 02:10 AM   #7
Ilgar
Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware 14.1, Slackware64 14.1
Posts: 916

Rep: Reputation: 87
Did you check the following thread about xpdf?

http://www.linuxquestions.org/questi...slowly-840078/
 
Old 11-15-2010, 02:50 AM   #8
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Ilgar View Post
Did you check the following thread about xpdf?
http://www.linuxquestions.org/questi...slowly-840078/
yes, but it doesn't help me or so I think.
 
Old 11-20-2010, 02:53 PM   #9
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Cannot find a simply or quick solution... I've tried to upgrade from 13.1 to current version. It's noticeable a general improve of performance within a X session (I use fluxbox). For example, thunderbird and firefox works better with a lower cpu% value. Another example is that Xv viewer return to works, like in the 13.0 (in 13.1 display a solid color instead of the image).

Xpdf problems still remains, sigh... but I continue to search for an answer to this issue.

Quote:
Originally Posted by catkin View Post
One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.
I've installed apvlv using the slackbuild from "slackbuilds.org" (Approved by: rworkman). A very light pdf viewer with vim key-bindings. A must have for me that I love vi(m).

:^)
 
Old 11-20-2010, 03:31 PM   #10
Ian John Locke II
Member
 
Registered: Mar 2008
Location: /dev/null
Distribution: Slackware, Android, Slackware64
Posts: 130

Rep: Reputation: 17
cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.
 
Old 11-20-2010, 03:46 PM   #11
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,231

Rep: Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573
Quote:
Originally Posted by Ian John Locke II View Post
cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.
I've been using apvlv for quite some time now and it has never crashed on me once...I haven't encountered any bugs at all (or at least none that I can recall). The only thing that I've missed compared to xpdf is colour inversion.
 
Old 11-20-2010, 03:57 PM   #12
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Ian John Locke II View Post
cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.
thanks for the info, but now I can only say that apvlv works well.
I will report if something goes bad.
 
Old 11-21-2010, 12:34 PM   #13
Ian John Locke II
Member
 
Registered: Mar 2008
Location: /dev/null
Distribution: Slackware, Android, Slackware64
Posts: 130

Rep: Reputation: 17
To be honest, I used it so long ago that the problems I ran into (which I can't remember exactly what they were) may have been fixed.
 
Old 11-21-2010, 02:21 PM   #14
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 5,962

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
Let me have a quick go at the xpdf issue

1. Try 'ldd /usr/bin/xpdf |grep found'
desired output is no output. Install anything that appears.

2. Ditto for /usr/bin/gs

3. Try in an xterm 'gs /path/to/some.pdf'. Make sure to use a text pdf, as gs (and therefore xpdf) really sweats over picture based pdfs. I could open a government report on Clerical Child Abuse quicker much faster than a local Pizza Hut menu. The drawing speed of the latter was painfully slow. It could just be the pdfs you have chosen to open.

4. Compare your results in gs with your results in xpdf for the same file. Xpdf may have a higher 'nice' value.
 
Old 11-21-2010, 02:32 PM   #15
cacao74
LQ Newbie
 
Registered: Sep 2009
Location: Turin, Italy
Distribution: Slackware
Posts: 14

Original Poster
Rep: Reputation: 0
Now I'm in current, but I can give some answer about the 13.1 (full fresh install):
Quote:
Originally Posted by business_kid View Post
Let me have a quick go at the xpdf issue

1. Try 'ldd /usr/bin/xpdf |grep found'
All dependencies satisfied (no "not found").
Quote:
2. Ditto for /usr/bin/gs
same as xpdf
Quote:
3. Try in an xterm 'gs /path/to/some.pdf'.
4. Compare your results in gs with your results in xpdf for the same file. Xpdf may have a higher 'nice' value.
I can't try these now...

:^)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
File transfers are slow and take 100% of CPU stringZ Linux - Software 3 12-07-2008 07:35 AM
vesafb on 2.6.15+ uses 100% cpu and is damn slow MuLaZ Linux - Hardware 2 03-29-2006 11:34 AM
Red Alert running slow in Wine, uses 100% CPU tomas412 Linux - Games 2 06-17-2005 02:07 AM
Grip - rips are very slow and take 100% cpu time Mad Merlin Linux - Software 3 05-02-2004 12:16 PM
redhat 8 running slow - CPU usage 100% jonnycarlos Linux - General 4 09-10-2003 04:33 AM


All times are GMT -5. The time now is 08:19 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration