On a new Asus U46E (i5-2430M CPU @ 2.40GHz, 8GB RAM) I continue observing frequent system "hiccups" that manifest themselves as
3-5 seconds delays in performing even the simplest operations like
ls on a small directory, or a simple editing operation in
vim.
All of this happening independently of my Desktop Environment, it happens also in Linux console, though it seems less severe.
This behavior is really annoying when I edit a file with
vim. I started to execute
vim editing sessions under
strace. Going back and forth between what I observed while editing, and the corresponding
strace logs, I decided to perform the following experiment: I opened (in a terminal) a small text file, and pasted a short text selection (20 short lines of text; I selected the text in a browser before firing
strace). The system hesitated for good 2-3 seconds before the pasted text appeared. I saved the file and exited. On my previous attempt of doing exactly the same the system hesitated for 4-5 seconds but unfortunately on that occasion I didn't run the process under
strace.
The whole operation took just a few seconds: from opening the file in
vim, pasting the contents of the buffer, to saving and exiting.
Then I opened the log: the bulk of the log file consisted of 3191 lines calling
select(...) of which exactly
3111 were like the line in the thread title:
Code:
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
Rarely in between interspersed were the 108 lines
with what looked like bytes of the text selection that was being pasted into.
I haven't noticed anything else in the log left by
strace which would catch my attention.
Reading
select()'s man page, as well as google-searching provided me with a basic introduction to the role
select() plays in monitoring file descriptors. I am not sure at all whether those thousands of
select(1, ... (Timeout) lines are an indication of anything going wrong, except possibly that for some reason some basic operations on open file descriptors are painfully slow on my brand new Asus, due to some scheduling issues or anything else.
For your information, the system was basically idle when I was performing all my tests. The operating system is 64 bit Fedora 16, fresh install peformed almost 4 weeks ago. No tweaks, no risky customizations. Basically, a default GNOME installation, though most of the time I am in fluxbox or in a console.
I would greatly appreciate anybody's ideas that could contribute to resolution the situation that makes using Fedora 16 on this laptop such a frustrating experience: the contrast between great specs and miserable performance cannot be greater.
Linear Mode
