Proposed patch: https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/741583

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/ce2be650b503aeabf9b2ecab449a296b9cff3d0c

commit ce2be650b503aeabf9b2ecab449a296b9cff3d0c
Author: Jonathan <jonathan.wright@arm.com>
Date: Thu Dec 07 23:22:49 2017

libchromeos-ui: big_little USE flag spawns 2 raster threads

The big_little USE flag is used to set the default number of software
raster threads on boards derived from chipset-rk3399. The number of
raster threads has been incremented from 1 to 2 as using a single thread
restricted performance unnecessarily.

The devices affected are Chromebooks Kevin and Bob.

This patch came out of a discussion here:
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/741583

BUG=chromium:791008
TEST=build for Kevin, check now has 2 CompositorTileWorker threads

Change-Id: I8af96a3f9fc039a2ccd9ee33b2d80e2a90d4dd54
Reviewed-on: https://chromium-review.googlesource.com/808940
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Jonathan Wright <jonathan.wright@arm.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/ce2be650b503aeabf9b2ecab449a296b9cff3d0c/libchromeos-ui/chromeos/ui/chromium_command_builder.cc

Is this done?

The patch in comment 3 is an alternative, less invasive change than originally proposed - it doesn't remove the 'big_little' flag but increments the number of threads spawned by it. This patch is on probation for 2 months to see if there are any issues in the wild. If not, the original patches can be upstreamed.

This will be revisited in ~2 months so this issue can be closed and reopened then.  

Hi gab,

We're interested in revisiting this older patch we had, which is aiming to increase the number of CompositorTileWorker threads available on the Samsung Chromebook Plus and similar chromebooks. 

Initially they were hard-limited to 1 thread, which we increased to 2, but our previous benchmarking showed that setting the number of threads to the number of cores available on the system always provides an improvement.

I'm CCing you in before we revisit this, because I wasn't sure if there were any plans to migrate the work of the CompositorTileWorkers to TaskSchedulerForegroundWorkers, rather than having distinct threads. In this case, we would automatically see an increase in the number of threads doing raster work to the number of cores on the system (well, minus one.)

There are hand-wavy intents to migrate these to TaskScheduler but no
concrete plans (i.e. that is the "plan" but no one is actively working on
it). The reason to use fewer physical threads IMO in the old world was to
avoid flooding other work. With TaskScheduler this is no longer a concern
as the scheduler will handle task dispatch.

Not having dedicated physical threads however means trickier rules for
BIG.little, right? Should we have double the physical threads on BIG.little
platforms and only ever schedule half of them (i.e. schedule USER_BLOCKING
work on different threads with high-priority cgroups to ease the kernel's
heuristics)?

Is this something you're interested in picking up?

Le mar. 5 juin 2018 09 h 55, stephen.kyle via monorail <
monorail+v2.4128881832@chromium.org> a écrit :