LinuxQuestions.org - New Install running SLOOOOOOOOOW

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - New Install running SLOOOOOOOOOW (https://www.linuxquestions.org/questions/linux-newbie-8/new-install-running-slooooooooow-327443/)

New Install running SLOOOOOOOOOW

Hey all,

I have a dual boot configuration using GRUB on my desktop PC. Dell Optiplex GX60, 2.40 celeron, 512 RAM, . The computer is only about 4 months old, so the hardware is fairly decent.

I installed SuSe 9.1 pro a few months ago, and it has been really running slow sinces the first day. So I decided to start again and re-installed it again, same result.

I have:
Grub boot loader
Windows XP Pro on the first partition

The problem is this:
Under any user, after I select to boot to Linux, it will take about 2 minutes to get passed the part where it shows the progress Icons. Then after the desktop background comes up it takes about an additional 3 minutes to populate the desktop with the task bar, icons.

After everything loads, which is a total of about 5 minutes, it seems to be a little slow on starting apps, but seems to move a decent speed once I am in the app. i.e. web browser and so on.

Any Ideas? Do i just need to tweak something?

see if your dma is on:

hdparm /dev/hda

you can also set this in yast

also kde takes a while to start up it's a very heavy wm you could try xfce or icewm or another "light weight" wm

Openbox and Fluxbox

I'm using Ubuntu 4.10 with a much older machine (PIII / 733 / 128).

GNOME actually loaded up very quickly. It would only start to lag badly when I was using Firefox with a few tabs open and trying to run some other program.

Both Openbox and Fluxbox, while not as "pretty" as GNOME, are great window managers if you want speed.

Lagging on faster machine as well.

Hey,

I read some other threads about machines "lagging" or pausing without I/O or 100% CPU. I have the following:

Pentium 4 2.66GHz
512MB RAM
40GB HDD with DMA enabled
Ubuntu Linux 6.10 (just installed it again)

Just recently - before the reinstalling my OS - I noticed that selecting to run programs from the menus didn't start the programs until 1-3 minutes later. The CPU utilization was low and idling as if I hadn't selected to have anything run. No disk usage either, as my LED isn't flickering.

For example, opening Firefox:
1) I go to Apps -> Internet -> Firefox
2) Less than 1 sec of disk activity
3) Many minutes of waiting around...
4) The harddrive starts grinding as it normally does when an app is loading to memory.
5) App is working.

When I use these programs, they function as they normally do when open. However even after a cold start of Firefox, or XMMS, or Gaim, or the Gnome-Terminal the delay still persists.

Any ideas? I'm stumped... :confused:

-AM

One possibility that comes to mind is the preemption model of the kernel (since I've just been messing around with that today). If it's set to fully preemptible, then it seems to make things start slower while being more responsive once they are running. So the voluntary preemption model is usually a better choice than full.
So if you could grep your kernel config (I'm not sure where it would be in SuSe) for PREEMPT to see if that's the case here?

This is what I found for my system:

Code:

$ cat /usr/src/linux-headers-2.6.17-10/kernel/Kconfig.preempt



choice

        prompt "Preemption Model"

        default PREEMPT_NONE



config PREEMPT_NONE

        bool "No Forced Preemption (Server)"

        help

          This is the traditional Linux preemption model, geared towards

          throughput. It will still provide good latencies most of the

          time, but there are no guarantees and occasional longer delays

          are possible.



          Select this option if you are building a kernel for a server or

          scientific/computation system, or if you want to maximize the

          raw processing power of the kernel, irrespective of scheduling

          latencies.



config PREEMPT_VOLUNTARY

        bool "Voluntary Kernel Preemption (Desktop)"

        help

          This option reduces the latency of the kernel by adding more

          "explicit preemption points" to the kernel code. These new

          preemption points have been selected to reduce the maximum

          latency of rescheduling, providing faster application reactions,

          at the cost of slighly lower throughput.



          This allows reaction to interactive events by allowing a

          low priority process to voluntarily preempt itself even if it

          is in kernel mode executing a system call. This allows

          applications to run more 'smoothly' even when the system is

          under load.



          Select this if you are building a kernel for a desktop system.



config PREEMPT

        bool "Preemptible Kernel (Low-Latency Desktop)"

        help

          This option reduces the latency of the kernel by making

          all kernel code (that is not executing in a critical section)

          preemptible.  This allows reaction to interactive events by

          permitting a low priority process to be preempted involuntarily

          even if it is in kernel mode executing a system call and would

          otherwise not be about to reach a natural preemption point.

          This allows applications to run more 'smoothly' even when the

          system is under load, at the cost of slighly lower throughput

          and a slight runtime overhead to kernel code.



          Select this if you are building a kernel for a desktop or

          embedded system with latency requirements in the milliseconds

          range.



endchoice



config PREEMPT_BKL

        bool "Preempt The Big Kernel Lock"

        depends on SMP || PREEMPT

        default y

        help

          This option reduces the latency of the kernel by making the

          big kernel lock preemptible.



          Say Y here if you are building a kernel for a desktop system.

          Say N if you are unsure.



$

I don't know if this is the right file or not. If I change this to voluntary preemption, is a recompile of the kernel necessary?

-AM

Here's something else to show what I mean (as an example):

Code:

$ time emacs

  

real    1m12.949s

user    0m0.236s

sys    0m0.036s

$ time emacs



real    1m11.323s

user    0m0.220s

sys    0m0.052s

$ time emacs



real    1m10.562s

user    0m0.232s

sys    0m0.072s

$

I close it right after I see it open.

The time is how long I'm sitting at my desk waiting, but the other times are how long my machine is actually taking to open up emacs, even after it has been loaded into memory...

:confused: :confused:

That file just shows what the options are. Maybe there's a copy of the config in /boot? or in /proc? Yes, changing it would require a recompile. But then I can't guarantee if that 's the answer here, 1m10.562s seems like more than just preemption would cause?

Here is something that seems to match your grep suggestion:

Code:

$ uname -r

2.6.17-11-generic

$ grep -i PREEMPT /boot/config-2.6.17-11-generic 

# CONFIG_PREEMPT_NONE is not set

CONFIG_PREEMPT_VOLUNTARY=y

# CONFIG_PREEMPT is not set

CONFIG_PREEMPT_BKL=y

$

It looks like I have voluntary preemption enabled in my kernel. I could swear this is something GUI related, but even

Code:

$ emacs -nw

takes that 1 minute to load in the console.