posix thread: Attempt to set audio threads to real time.

base/threading/platform_thread_posix.cc

Index: base/threading/platform_thread_posix.cc
diff --git a/base/threading/platform_thread_posix.cc b/base/threading/platform_thread_posix.cc
index 43e58b73375a0c3273422d9c28e10150d3835197..a4d23cfe0afe825882dc94fc727dab741a10df0a 100644
--- a/base/threading/platform_thread_posix.cc
+++ b/base/threading/platform_thread_posix.cc
@@ -48,6 +48,18 @@ struct ThreadParams {
   ThreadPriority priority;
 };
 
+#if defined(OS_LINUX)
+static int SetCurrentThreadRealTime() {
+  const int kRealTimePrio = 8;
+
+  struct sched_param sched_param;
+  memset(&sched_param, 0, sizeof(sched_param));
+  sched_param.sched_priority = kRealTimePrio;
+
+  return pthread_setschedparam(pthread_self(), SCHED_RR, &sched_param);
+}
+#endif
+
 void SetCurrentThreadPriority(ThreadPriority priority) {
 #if defined(OS_LINUX) || defined(OS_ANDROID)
   switch (priority) {
@@ -56,6 +68,11 @@ void SetCurrentThreadPriority(ThreadPriority priority) {
       break;
     case kThreadPriority_RealtimeAudio:
 #if defined(OS_LINUX)

[DaveMoore, 2013/05/23 17:20:16]

If we're doing something different on OS_CHROMEOS we shouldn't also mess with
the niceness of threads. It's not clear how it will interact with the cgroups
usage.

[dgreid, 2013/05/23 17:24:47]

This change stops switching the niceness of the thread, instead changing its
scheduler.  There is also a platform side change that re-instates the
restriction against setting a favorable nice level.

[DaveMoore, 2013/05/23 18:21:12]

Then I think we should explicitly avoid ever setting the niceness on chromeos,
even if SetCurrentThreadRealTime() fails.
On 2013/05/23 17:24:47, dgreid wrote:

[dgreid, 2013/05/23 18:36:28]

We still want to set the nice level if it is positive.  It looks like we might
want to still allow for negative values for Display?  That's new to me.

What do we gain by not setting the nice value in the fall through on ChromeOS?
we want to do it for linux. On ChromeOS it won't happen unless the system config
changes and even then it would just fail.

[DaveMoore, 2013/05/23 20:16:31]

It's at best misleading, and at worst will lead to hard to diagnose problems.
Basically if you expect the realtime scheduling to work on Chromeos you should
count on it and spit out an error if it fails. There really should be a test
somewhere that confirms that this functionality works on cros. Is there? I
haven't see the cros changes. I know that the cgroup stuff has been fragile as
there are a few places that have to agree on how it works.

On 2013/05/23 18:36:28, dgreid wrote:

[dgreid, 2013/05/23 20:37:49]

Thanks Dave,

Not sure about the consequences of this, but we should certainly be logging
failures here.  I'll add a return and a log.
There are no tests of any of this.  If there is a way to get the thread id of an
audio thread to autotest than it would be easy to verify it has the correct
priority.  Is that easy to get?

It would be much better to add a test since this has the same three places
needing to agree as cgroups does.

+      if (SetCurrentThreadRealTime() == 0)
+        // Got real time priority.
+        return;
+
+      // Otherwise try to set an advantageous nice level.
       const int kNiceSetting = -10;
       // Linux isn't posix compliant with setpriority(2), it will set a thread
       // priority if it is passed a tid, not affecting the rest of the threads