<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Tomorrow I can take some time to try trace what is the source of this<br>
behavior. All suggestions would be appreciated<br></blockquote><div><br>i've once asked a (top) linux developer for assistance on some issues with sound and mc, and generally anything involving i/o and scheduler, in my opinion. he told me to look at /proc/sys/kernel/sched_* for some tweakable numbers. but in his opinion, the problem is the i/o. <br>
<br>about i/o issues, there's a thread saying that:<br><br>"<pre><font size="4">Now I think the main problem is having the filesystem block (and do IO) in<br>inode reclaim. The problem is that this doesn't get accounted well and<br>
penalizes a random allocator with a big latency spike caused by work<br>generated from elsewhere.<br> <br>I think the best idea would be to avoid this. By design if possible, or<br>by deferring the hard work to an asynchronous context. If the latter,<br>
then the fs would probably want to throttle creation of new work with<br>queue size of the deferred work, but let's not get into those details.<br> <br>Anyway, the other obvious thing we looked at is the iprune_mutex which is<br>
causing the cascading blocking. We could turn this into an rwsem to<br>improve concurrency. It is unreasonable to totally ban all potentially<br>slow or blocking operations in inode reclaim, so I think this is a cheap<br>
way to get a small improvement.<br> <br>This doesn't solve the whole problem of course. The process doing inode<br>reclaim will still take the latency hit, and concurrent processes may end<br>up contending on filesystem locks. So fs developers should keep these<br>
problems in mind.</font><br></pre>"<br><a href="http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.32/ChangeLog-2.6.32-rc1">http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.32/ChangeLog-2.6.32-rc1</a><br>
<br>as much as i understand those things, the bigger the filesystem, the bigger the i/o slowdown. and if if you are "lucky" as i am to have one of those infamous green western digital hard disks on a low end motherboard, the system can crawl very easily. hope this will help, somehow :)<br>
<br>
</div></div>