pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
mkkp4x4 at gmail.com
Wed Jan 19 17:44:41 UTC 2011
2011/1/19 cornel panceac <cpanceac at gmail.com>:
>> 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.
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 :)
> 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.
More information about the test