<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Phil,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div><br>
</div>
<div>Thanks for using Argobots! The following is my answers to your questions in addition to some tips.</div>
<div>We would appreciate it if you could share more information about your workload and the purpose so that we can give you more specific suggestions. Also, we welcome any feature requests and bug reports.</div>
<div><br>
</div>
<div>1. How to change a scheduler's event frequency?</div>
<div>1.1. Predefined scheduler</div>
<div>First, there is no way to dynamically change the event frequency (even if you hack ABT_sched or a pointer you used in ABT_sched_get_data()... since event_freq is loaded to a local variable).</div>
<div>https://github.com/pmodels/argobots/blob/main/src/sched/basic_wait.c#L102</div>
<div>Currently, using a special ABT_sched_config when you create a scheduler is the cleanest and the only way to change the event frequency.</div>
<div>```</div>
<div>ABT_sched_config config;</div>
<div>int new_freq = 16; // The default value is 50 (https://github.com/pmodels/argobots/blob/main/src/arch/abtd_env.c#L13)</div>
<div>ABT_sched_config_create(&config, ABT_sched_basic_freq, 16, ABT_sched_config_var_end);</div>
<div>```</div>
<div>1.2. Custom scheduler<br>
</div>
<div>You can call ABT_xstream_check_events() more frequently after calling ABT_info_trigger_print_all_thread_stacks() (e.g., when a global flag is on, a scheduler calls ABT_xstream_check_events() in every iteration).</div>
<div><br>
</div>
<div>2. ABT_info_trigger_print_all_thread_stacks()</div>
<div>ABT_info_trigger_print_all_thread_stacks() is designed for deadlock/livelock detection, so if your program is just (extremely) slow, ABT_info_trigger_print_all_thread_stacks() might not be a right routine to try.</div>
<div><br>
</div>
<div>> The first example I tried appeared to essentially defer dump until shutdown.</div>
<div>When one of your ULTs encounters a deadlock, the scheduling loop might not be called. You might want to set timeout for ABT_info_trigger_print_all_thread_stacks(). For example, the following test will forcibly print stacks after 3.0 seconds even if some
execution streams have not reached ABT_xstream_check_events().</div>
<div>https://github.com/pmodels/argobots/blob/main/test/basic/info_stackdump2.c#L30</div>
<div>This is dangerous (I mean, it can dump a stack of a running ULT), so Argobots does not guarantee anything but it might be helpful to understand a deadlock issue sometimes.</div>
<div><br>
</div>
<div>===</div>
<div><br>
</div>
<div>3. Some tips</div>
<div>3.1. gdb</div>
<div>I would use gdb if it would be available to check a deadlock/performance issue. For example, if a program looks hanging, I will attach a debugger to that process and see what's happening.</div>
<div>3.2. libunwind for ABT_info_trigger_print_all_thread_stacks()</div>
<div>Unless you are an extremely skillful low-level programmer, I would recommend you enable libunwind for better understanding of stacks. By default, ABT_info_trigger_print_all_thread_stacks() dumps raw hex stack data.</div>
<div>3.3. "occasionally tied up in system calls"</div>
<div>I'm not sure if it's happening in the Argobots runtime (now Argobots uses futex for synchronization on external threads), but if you are calling ABT_info_trigger_print_all_thread_stacks() in a signal handler, please be aware that system calls terminate
(e.g., futex, poll, or pthread_cond_wait) if a signal hits the process.</div>
<div>(Argobots synchronization implementation is aware of it and should not be affected by an external signal. This property is thoroughly tested: https://github.com/pmodels/argobots/blob/main/test/util/abttest.c#L245-L287)</div>
<div>Note that the user can call ABT_info_trigger_print_all_thread_stacks() on a normal thread without any problem. It is implemented just in an async-signal safe manner.</div>
<div>3.4. Stack dump</div>
<div>ABT_info_print_thread_stacks_in_pool() is a less invasive way to print stacks, especially if you know a list of pools. It prints stacks immediately. Basically, ABT_info_trigger_print_all_thread_stacks() sets a flag to call ABT_info_print_thread_stacks_in_pool()
for all pools after all the execution streams stop in ABT_xstream_check_events().</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Shintaro</div>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Phil Carns via discuss <discuss@lists.argobots.org><br>
<b>Sent:</b> Wednesday, April 14, 2021 2:18 PM<br>
<b>To:</b> discuss@lists.argobots.org <discuss@lists.argobots.org><br>
<b>Cc:</b> Carns, Philip H. <carns@mcs.anl.gov><br>
<b>Subject:</b> [argobots-discuss] modifying scheduler event frequency?</font>
<div> </div>
</div>
<div>
<p>Hi all,</p>
<p>Is there a clean way to change a scheduler's event frequency on the fly?</p>
<p>Browsing the API, I see two possibilities:</p>
<ul>
<li>set it when the scheduler is first created (using ABT_sched_basic_freq?)</li><li>set it dynamically by manipulating the ABT_sched_get_data() pointer, but this seems especially dangerous since the sched data struct definition isn't public (i.e. it could cause memory corruption if the internal struct def changed)<br>
</li></ul>
<p>For some context (in case there is a different way to go about this entirely), I'm trying to figure out how to get ABT_info_trigger_print_all_thread_stacks() to print information more quickly, which IIUC relies on getting the active schedulers to call get_events()
sooner.</p>
<p>I'm happy to add some explicit ABT_thread_yield() shortly after the ABT_info_trigger_print_all_thread_stacks() to at least get the calling ES to execute it's scheduler loop immediately, but I think that won't matter much if it doesn't trip the frequency
counter when I do it.</p>
<p>Without this (at least with the _wait scheduler and threads that are occasionally tied up in system calls) I think the stack dump is likely to trigger too late to display what I'm hoping to capture when I call it. The first example I tried appeared to essentially
defer dump until shutdown.<br>
</p>
<p>thanks!</p>
<p>-Phil<br>
</p>
</div>
</body>
</html>