Changing priority of a particular thread

[Anton Vayvod]

Hi all,

is there a way in Chrome to rise/lower priority for particular thread?

There's a situation on Chrome OS when IO and FILE threads eat most of CPU (loading default extensions, initializing sync, etc - top gives 200% to both chrome processes launched) so even on a separate thread video capturing is slower than expected. I think if I could raise video thread priority above the rest, it'd have enough cycles to work reasonably.

Thanks,

Anton.

[Evan Martin]

Did you try pthread_setschedparam? It has some sched_priority function.

http://linux.die.net/man/3/pthread_setschedparam

I kinda think we shouldn't be initializing sync /extensions so early
if they are conflicting with something important like this.

[Evan Martin]

On Wed, Oct 20, 2010 at 12:17 PM, Evan Martin <ev...@chromium.org> wrote:
> On Wed, Oct 20, 2010 at 12:05 PM, Anton Vayvod <ava...@chromium.org> wrote:
>> is there a way in Chrome to rise/lower priority for particular thread?
>> There's a situation on Chrome OS when IO and FILE threads eat most of CPU
>> (loading default extensions, initializing sync, etc - top gives 200% to both
>> chrome processes launched) so even on a separate thread video capturing is
>> slower than expected. I think if I could raise video thread priority above
>> the rest, it'd have enough cycles to work reasonably.
>
> Did you try pthread_setschedparam?  It has some sched_priority function.
> http://linux.die.net/man/3/pthread_setschedparam

Er, I guess this makes more sense.
http://linux.die.net/man/3/pthread_setschedprio
I don't really know what I'm talking about, though. I was mailing
more to emphasize the below point:

[William Chan (陈智昌)]

Why do these suck up 100% of cpu?  How long does that happen?  Are these affecting jank (IO thread is supposed to be responsive)?

 

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Scott Hess]

Fixing this kind of thing by raising the thread priority is like
fixing a race condition by adding a sleep(). In a system like Chrome
this kind of thing could quickly result in an arm's race as each
sub-group decides that _their_ thread is really more important than
that other thread.

Evan's comment is spot on. If these startup operations are causing
your thread to be starved, then they are causing other threads to be
starved.

-scott

On Wed, Oct 20, 2010 at 12:05 PM, Anton Vayvod <ava...@chromium.org> wrote:

[Darin Fisher]

Right.  We have historically resisted playing with thread priorities too much.  It is often not the right solution.

-Darin

[Aaron Boodman]

On Wed, Oct 20, 2010 at 12:05 PM, Anton Vayvod <ava...@chromium.org> wrote:

I presume you're talking about video capture on the login screen? The
code should be changed so that things like sync, extensions, and other
heavyweight services do not initialize until the login is complete and
the correct profile is selected. I thought that this was already true
for extensions, so it doesn't make sense to me that default extensions
is contributing to the problem.

- a

[Nikita Kostylev]

Video capture happens exactly after login is complete.

On the one hand we want to delay those things so that they don't slow down camera operations but on the other hand we want to make sure that new profile is synced as fast as possible.

So the solution might be delay some thins like sync for new account login which requires video capture.

21 октября 2010 г. 6:49 пользователь Aaron Boodman <a...@chromium.org> написал:

I presume you're talking about video capture on the login screen? The
code should be changed so that things like sync, extensions, and other
heavyweight services do not initialize until the login is complete and
the correct profile is selected. I thought that this was already true
for extensions, so it doesn't make sense to me that default extensions
is contributing to the problem.

--
Nikita

[Dmitry Polukhin]

There are foreground tasks like video playing/capturing and background like update or some other actioned that can be delayed without any problem. Setting higher priority to foreground user visible tasks and lower priority for background things looks reasonable to me.

--

[Sergey Ulanov]

If you have 3 threads competing for two processors, each thread should get at least 50% of one processor. If 50% of one processor is not enough to capture a video from web camera, you are probably doing something wrong, and changing threads priorities isn't going it fix anything.

I looked in the camera code some time ago, and if I remember correctly, Laczos resampling was used to resize video frames from the camera. This may explain why camera thread needs so much CPU time. Did you look into optimizing this code? Lanzos resampling is way too expensive for such kind of application, and I think bilinear scaling would be much more appropriate. You should also consider using the optimized video resampler that we use for HTML5 video. It does colorspace conversion and resampling in a single pass, so if may significantly improve performance for you when you get YUV image from the camera.

[Anton Vayvod]

I think Chromium OS should work fine even on one core.

I removed Laczos resampling some time ago (well, there's one place left actually, but it's not executed).

Will look into using video resampler. Any pointers to its code?

[Andrew Scherkus]

Assuming you have planar 12-bit YUV the functions in /src/media/base/yuv_convert.h should work.

Andrew

[Sergey Ulanov]

On Fri, Oct 22, 2010 at 3:17 AM, Anton Vayvod <ava...@chromium.org> wrote:

I think Chromium OS should work fine even on one core.

Well, this doesn't change anything, does it? How much CPU time the camera thread needs when there is no background activity? If it is more than 10% then something is wrong.

 

I removed Laczos resampling some time ago (well, there's one place left actually, but it's not executed).

Will look into using video resampler. Any pointers to its code?

It's in src/media/base/yuv_convert.[h|cc] and src/media/base/yuv_row.[h|cc]. Because you get YUYV from the camera you will ether need to add conversion to YV12, or implement YUYV support.

Your current code has 7 multiplications in convert_yuv_to_rgba(), and it is called for each pixel. I can see how this may become a bottleneck, especially on Atom.