Tomorrow I can take some time to try trace what is the source of this
behavior. All suggestions would be appreciated
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.
about i/o issues, there's a thread saying that:
"
Now I think the main problem is having the filesystem block (and do IO) in"
inode reclaim. The problem is that this doesn't get accounted well and
penalizes a random allocator with a big latency spike caused by work
generated from elsewhere.
I think the best idea would be to avoid this. By design if possible, or
by deferring the hard work to an asynchronous context. If the latter,
then the fs would probably want to throttle creation of new work with
queue size of the deferred work, but let's not get into those details.
Anyway, the other obvious thing we looked at is the iprune_mutex which is
causing the cascading blocking. We could turn this into an rwsem to
improve concurrency. It is unreasonable to totally ban all potentially
slow or blocking operations in inode reclaim, so I think this is a cheap
way to get a small improvement.
This doesn't solve the whole problem of course. The process doing inode
reclaim will still take the latency hit, and concurrent processes may end
up contending on filesystem locks. So fs developers should keep these
problems in mind.
http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.32/ChangeLog-2.6.32-rc1
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 :)
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
