Resending with lkml Cc:ed. On Thu 28.Feb'08 at 11:54:04 -0800, Ray Lee wrote:Thanks Ingo! Hm, but I remember that my desktop became unusable. I was experiencing latencies _much_ higher than msecs. But I think I have an explanation for this low number, if you excuse my attempt to understand this. Could it be that your debug script generated these numbers while fgfs was being killed, and then it felt no more the bad latencies fgfs was causing? This was the first scenario: 1) Start 'fgfs' as normal user. 2) Wait a few seconds until fgfs' message "loading scenery objects" appeared. 3) Everything becomes _very_ slow (measured in seconds, not msecs), so I notice something is wrong (at least I thought it was). 4) Killed fgfs with Ctrl-c. 5) I go to Ingo's page and download his debug scripts. 6) Preparing for the battle to follow, I run cfs-debug-info-clear.sh 7) Start 'fgfs' and system becomes slow while loading scenery objects. 8) I try to reach the mrxvt terminal to run cfs-debug-info.sh. Each letter I type takes seconds to appear. 9) I manage to start cfs-debug-info.sh. I could read the first line after a few seconds: sched info dump (of tasks, modules, hw, dmesg, config, fs): But I am sure I did not see the "gathering statistics for 15 seconds ..." As that was the first time ever that I used this script, I didn't even know what I was supposed to do, but I was waiting for more than a minute and nothing happened. 10) I managed to change tab and kill fgfs with Crtl-c. 11) I got back to the debug script tab and waited a few seconds for it to finish. 12) That is the debug log which I put in the page mentioned in the first email. I am sorry to especulate about it, but maybe the script got the latencies after (or meanwhile) I was killing fgfs. I have rebooted and tried to repeat the experiment, but I couldn't reproduce the bad interactivity I reported earlier. Flightgear loaded the scenery (which it did not do before) and the airplane appeared in the screen. The game was slow, but I had a very good usability of the desktop and I could type things almost normally, I could switch desktops etc. Definitely not what happened before! So I am sorry for the noise, but something bad happened before and unfortunately I am not sure I could run Ingo's debug script correctly. I'll be more patient if that happens again. Anyway, I want to thank Ingo and Ray for their replies and would like to humbly ask: Is it an scheduler anomaly if 'se.wait_max' is bigger than 40 msecs for _any_ of the processes which appear in the debug script log? In other words, is the scheduler mathematically build to not allow latencies higher than 40 msecs? --
| Ian Campbell | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Justin Piszcz | Linux Software RAID 5 Performance Optimizations: 2.6.19.1: (211MB/s read & 195... |
| Alan | Re: [RFC] Heads up on sys_fallocate() |
| Matthias Scheler | Re: HEADS UP: timecounters (branch simonb-timecounters) merged into -current |
| David Laight | long usernames |
| Quentin Garnier | Re: Understanding foo_open, foo_read, etc. |
| Jared D. McNeill | Breaking binary compatibility for /dev/joy |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
