This are the problems I have faced thus far:
1.When doing heavy disk usage mouse start to lag. DMA is enabled
2.A program can use 100% CPU even if it leads the system almost unresponsive. Isn't there a way that even if an app is using 100% CPU that the rest of the system should still be responsive?

I have posted this thread into the KERNEL because I believe that problem is the scheduler involved.

I have compiled Vanilla kernel 2.6.19.2. Perhaps I should also use the ConKolivas patchset. Would that help?

The kernel preempt settings:

I'm not quite sure, but just to give an opinion, I myself have not met either of those problems this far: I do some CPU-intensive tasks like handling RAW photos (the bare file takes at least 50MB of disk space, compared to a JPEG which takes only a few MB or less) and during that my mouse isn't lagging; the program I'm using may itself become a little freezy or not-so-fast-responsible, at times even stop responding for a moment, but I can still use the rest of the system with ease. Other tasks do work a bit slower when the photo program is doing some heavy work, but generally the system works like a charm. I'm using a kernel version of 2.6.17 from Ubuntu 6.10 reposities, and have quite a regular system with 512MB DDR memory and 1GB of swap space available.

Not sure why your system is freezing (that sounds what Windows does, even if you didn't have any heavy duty for it), but it sounds definitely interesting; do you notice same things when using a stock kernel instead of a self-compiled one?

EDIT: forgot to mention, the CPU is an AMD Sempron, 1800MHz.

With the regular kernel I still get the same problem.

It is entirely possible that the application is bogging down ... not Linux itself, but rather X-Windows. That is to say, the GUI subsystem.

It depends entirely upon the nature of the application.

---

Here's the soap: you see two things concurrently, and you assume that they are related:

• CPU utilization is 100%.
• The system is bogged down.

But it ain't necessarily so.

The Linux dispatcher wants to keep the CPU as busy as possible. When there is 100% demand for the CPU and the dispatcher is able to service that demand .. great! It is when demand exists that the dispatcher is not able to fulfill that you have troubles. Repeat: "100% CPU utilization" is goodness!

Therefore, the co-incident appearance of these two symptoms tells you something else; something different than what you might expect. It says that whatever is bogging-down the system, as seen by you the end-user, is not preventing the dispatcher from launching tasks at 100% efficiency. The tasks are therefore not blocking one another; there isn't a system-resource contention. Ergo, there must be some kind of lock or mutex contention. A flood of messages could do that. A backlog of un-processed GUI messages could do it too.

Saturated bus?

The mouse start to lag
What kind of file system do you use?
Did you check your speed and dma with
hdparm -d 1 /dev/hda
hdparm -tT /dev/hda
?

SUNDIALSVCS
But shouldn't LINUX when an app eats 100% of CPU still try to be as responsive as possible and not allocate every CPU power to that specific GUI application making the mouse LAG? This is what Winblows does

QUAKEBOY02
What do U mean, I do not understand U?

NX5000
I tried XFS, JFS, ReiserFS, Reiser4 thus far and all of have this problem. So we can rule out FS.

I don't think its the application that makes your mouse lag. It's a kernel task that eats the cpu.
I tend to prefer ext3 or ext4, which is the default filesystem for linux. XFS and reiser do exactly what you say on my system and that's not what I want since it's a desktop machine.
Depending on the application and how it is coded, the underlying kernel task will take over on your activities... nothing new. The same would happen in winblows probably.
What is your HZ value in .config?

"QUAKEBOY02
What do U mean, I do not understand U?"

I was referring to the possibility that your processes are causing so much IO activity that the bus could saturate. IOW, it's pushing as many bytes as it can, so anything more, including mouse activity, simply has to get in line. I've seen the laggy mouse issue on my MSI-boarded machine which has a slower bus than my ASUS machine. I've been using it to compile the kernel, rip DVDs etc. If I get too much of that going on at once, the mouse gets laggy and the machine isn't as responsive. I think it helped somewhat when I changed the kernel timer frequency to 1000hz.

my HZ value is 1000.
I always thought that the kernel never dedicates all of the processing power to a single app and that it always leaves some breading room. Is this not correct?

I don't think its the scheduler that is the problem in your setup. Probably the flow of data to the bus.
Can you give the result of this:
egrep IOSCH /proc/config**

On newer 2.6.20 kernels you can do better io limiting if its only a problem of disk access.

There are different policies for giving access to a thread, some are done by the kernel some are done by the thread itself.
I didn't see any real improvement for my usage with the CK patches.
There are also the -mm patches...

NX5000
Here's the output:

That was the tool I was talking about : ionice

On how many linux distro did you do the test?

Can you give me one application that exhibits the problem, so that I can try on my box? Every setup is different..

With CONFIG_IOSCHED_AS as the scheduler?
http://www.mjmwired.net/kernel/Docum...hing-sched.txt
Also some kernels (like the one in fedora 6) set CONFIG_PREEMPT_VOLUNTARY on

The scheduler is getting heavy modification since the 2.6. You have to try several configurations. I'm far from being an expert.

Trying Suse, Fedora or others would be helpful...

Why don't you use the ubuntu kernel and see what that does?
Also there might be something enabled by default in ubuntu which doesn't play nice with a vanilla kernel.

Mouse-lag can come from many sources. In short, there are many possible interactions that could cause the behavior you are experiencing. Therefore, your first step should be to strive to diagnose where it is actually coming from. Don't just "thrash at it and see if something works."

Don't swap kernels. Don't start diddling with scheduler parameters or hard-disk queueing options. (Those are designed to balance multiple streams of I/O-requests; they're useless with only one.)

"Don't slap at it ... think." (Notez vous: I do not intend that to be a desparaging nor insulting comment!)

So, grab a legal-pad and a number-two pencil and start writing down as many possibilities as you can think of.

If DMA is on, then we know that the actual data-transfer happens without CPU intervention, the CPU being notified only when the transfer is complete. If the CPU is running at 100% all the while, then the bus cannot be saturated; nor would one expect it to be in any realistic system.

We don't know if the system is paging. (Find out.)

Anything at all having to do with "the mouse" on Linux involves several subsystems due to the client/server nature of the GUI. It is still a trivial amount of processing.

The most likely culprit is still probably that an application is either burning up whole time-slices, or that there are too many entries in the runlist and the scheduler has to round-robin between them.

Does this application intermingle CPU-intensive work and interactive work in the same thread? If so, that produces a paradox for the scheduler.

One good way to try to isolate the culprit is by running the program from a shell with the nice command, which lowers its scheduling priority. Oddly enough, resource-intensive programs that are niced often run faster and complete their work sooner, and if this application is the major source of the problem, the mouse-lag will disappear.