Add clo option -scheduling-quantum=<number> to control scheduler time slice.

This option can be useful when tracking race conditions which are sensitive
to thread scheduling.

coregrind/m_main.c

@@ -202,6 +202,8 @@ static void usage_NORETURN ( int need_help )
 "         where hint is one of:\n"
 "           lax-ioctls lax-doors fuse-compatible enable-outer\n"
 "           no-inner-prefix no-nptl-pthread-stackcache fallback-llsc none\n"
+"    --scheduling-quantum=<number>  thread-scheduling timeslice in number of\n"
+"           basic blocks [100000]\n"
 "    --fair-sched=no|yes|try   schedule threads fairly on multicore systems [no]\n"
 "    --kernel-variant=variant1,variant2,...\n"
 "         handle non-standard kernel variants [none]\n"
@@ -622,6 +624,8 @@ static void process_option (Clo_Mode mode,
    else if VG_BOOL_CLOM(cloPD, arg, "--trace-children",   VG_(clo_trace_children)) {}
    else if VG_BOOL_CLOM(cloPD, arg, "--child-silent-after-fork",
                         VG_(clo_child_silent_after_fork)) {}
+else if VG_INT_CLOM(cloPD, arg, "--scheduling-quantum", 
+                    VG_(clo_scheduling_quantum)) {}
    else if VG_STR_CLO(arg, "--fair-sched",        tmp_str) {
       if (VG_(Clo_Mode)() != cloP)
          ;

coregrind/m_options.c

@@ -150,6 +150,11 @@ Bool   VG_(clo_debug_dump_frames) = False;
 Bool   VG_(clo_trace_redir)    = False;
 enum FairSchedType
        VG_(clo_fair_sched)     = disable_fair_sched;
+/* VG_(clo_scheduling_quantum) defines the thread-scheduling timeslice,
+   in terms of the number of basic blocks we attempt to run each thread for.
+   Smaller values give finer interleaving but much increased scheduling
+   overheads. */
+Word   VG_(clo_scheduling_quantum) = 100000;
 Bool   VG_(clo_trace_sched)    = False;
 Bool   VG_(clo_profile_heap)   = False;
 UInt   VG_(clo_progress_interval) = 0; /* in seconds, 1 .. 3600,

coregrind/m_scheduler/scheduler.c

@@ -101,11 +101,6 @@
 
 /* ThreadId and ThreadState are defined elsewhere*/
 
-/* Defines the thread-scheduling timeslice, in terms of the number of
-   basic blocks we attempt to run each thread for.  Smaller values
-   give finer interleaving but much increased scheduling overheads. */
-#define SCHEDULING_QUANTUM   100000
-
 /* If False, a fault is Valgrind-internal (ie, a bug) */
 Bool VG_(in_generated_code) = False;
 
@@ -1389,7 +1384,7 @@ VgSchedReturnCode VG_(scheduler) ( ThreadId tid )
    
    vg_assert(VG_(is_running_thread)(tid));
 
-   dispatch_ctr = SCHEDULING_QUANTUM;
+   dispatch_ctr = VG_(clo_scheduling_quantum);
 
    while (!VG_(is_exiting)(tid)) {
 
@@ -1440,7 +1435,7 @@ VgSchedReturnCode VG_(scheduler) ( ThreadId tid )
 	 n_scheduling_events_MAJOR++;
 
 	 /* Figure out how many bbs to ask vg_run_innerloop to do. */
-         dispatch_ctr = SCHEDULING_QUANTUM;
+         dispatch_ctr = VG_(clo_scheduling_quantum);
 
 	 /* paranoia ... */
 	 vg_assert(tst->tid == tid);

coregrind/pub_core_options.h

@@ -209,6 +209,8 @@ extern Bool  VG_(clo_trace_redir);
 /* Enable fair scheduling on multicore systems? default: NO */
 enum FairSchedType { disable_fair_sched, enable_fair_sched, try_fair_sched };
 extern enum FairSchedType VG_(clo_fair_sched);
+/* thread-scheduling timeslice. */
+extern Word   VG_(clo_scheduling_quantum);
 /* DEBUG: print thread scheduling events?  default: NO */
 extern Bool  VG_(clo_trace_sched);
 /* DEBUG: do heap profiling?  default: NO */

docs/xml/manual-core.xml

@@ -2303,6 +2303,23 @@ need to use them.</para>
     </listitem>
   </varlistentry>
 
+  <varlistentry id="opt.scheduling-quantum" xreflabel="--scheduling-quantum">
+    <term>
+      <option><![CDATA[--scheduling-quantum=<number>   [default: 100000] ]]></option>
+    </term>
+    <listitem>
+      <para>The <option>--scheduling-quantum</option> option controls
+      the maximum number of basic blocks executed by a thread before releasing
+      the lock used by Valgrind to serialise thread execution.  Smaller values
+      give finer interleaving but increases the scheduling overhead. Finer
+      interleaving can be useful to reproduce race conditions with helgrind or
+      DRD.  For more details about the Valgrind thread serialisation scheme and
+      its impact on performance and thread scheduling, see
+      <xref linkend="&vg-pthreads-perf-sched-id;"/>.
+      </para>
+    </listitem>
+  </varlistentry>
+
   <varlistentry id="opt.fair-sched" xreflabel="--fair-sched">
     <term>
       <option><![CDATA[--fair-sched=<no|yes|try>    [default: no] ]]></option>

none/tests/cmdline1.stdout.exp

@@ -115,6 +115,8 @@ usage: valgrind [options] prog-and-args
          where hint is one of:
            lax-ioctls lax-doors fuse-compatible enable-outer
            no-inner-prefix no-nptl-pthread-stackcache fallback-llsc none
+    --scheduling-quantum=<number>  thread-scheduling timeslice in number of
+           basic blocks [100000]
     --fair-sched=no|yes|try   schedule threads fairly on multicore systems [no]
     --kernel-variant=variant1,variant2,...
          handle non-standard kernel variants [none]

none/tests/cmdline2.stdout.exp

@@ -115,6 +115,8 @@ usage: valgrind [options] prog-and-args
          where hint is one of:
            lax-ioctls lax-doors fuse-compatible enable-outer
            no-inner-prefix no-nptl-pthread-stackcache fallback-llsc none
+    --scheduling-quantum=<number>  thread-scheduling timeslice in number of
+           basic blocks [100000]
     --fair-sched=no|yes|try   schedule threads fairly on multicore systems [no]
     --kernel-variant=variant1,variant2,...
          handle non-standard kernel variants [none]