2011/1/19 cornel panceac <cpanceac@xxxxxxxxx>: > >> 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 And where the famous 2.6.37 vfs scalability fixes? :) > > as much as i understand those things, the bigger the filesystem, My /home on laptop has 8 or 16GB (it's only a test system) - I've got larger file systems > 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 I'm lucky and I've got two infamous [ 1.585384] ata3.00: ATA-8: WDC WD10EADS-00L5B1, 01.01A01, max UDMA/133 [..] [ 1.602188] ata4.00: ATA-8: WDC WD15EADS-00P8B0, 01.00A01, max UDMA/133 I also have one famous [ 2.907613] ata6.00: ATA-8: WDC WD1001FALS-00E8B0, 05.00K05, max UDMA/133 > on a low end motherboard, on atom 330 board. No problems so far :) > the > system can crawl very easily. hope this will help, somehow :) > Thanks for the pointer. I doubt that this problem is related to kernel space issue. I'll try to track down it this week. -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
