pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)

[Michał Piotrowski]

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.
>
> "
> 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/