<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 4:03 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 3:00 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jonathan,</blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is not much support available out-of-the-box in RTEMS for<br>
servers, other than some academic implementation of the constant<br>
bandwidth server (CBS) for uniprocessor EDF.<br></blockquote><div><br></div><div>The affinity should work if deadline tasks and priority based tasks never</div><div>are assigned to the same core.</div></div></div></blockquote><div><br></div><div>My application is partitioned three ways: rate-monotonic tasks that are scheduled using the kernel tick and the rate monotonic manager, rate-monotonic tasks that are scheduled by sending rtems_events from a regular ISR, and throughput-oriented tasks that have lower priority than everything else.  There are only two cores physically present.  So I think I can keep the two realtime task categories distinct with 1:1 affinity and give the remaining time to throughput tasks using 1:any affinity.</div><div><br></div><div>The result is that the core that is managed using the rate-monotonic manager should be schedulable using EDF's analysis, and the core that is managed by sending events from interrupts should be schedulable using fixed-priority rate-monotonic analysis.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>If you do this, you could experiment with affinity and then consider moving</div><div>to a partitioned scheduler setup with some cores running based on </div><div>deadline and other cores running threads based on priority.</div></div></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>The SMP EDF scheduler only supports pinning (single core) and not </div><div>affinity sets so the clustered scheduling may be the more optimal</div><div>alternative.</div></div></div></blockquote><div><br></div><div>Its a 2-core system, so I don't need the flexibility afforded by using clustered scheduling instead of affinity.<br></div><div> <br clear="all"></div></div><div>Thanks,<br></div>-- <br><div dir="ltr" class="gmail_signature">Jonathan Brandmeyer<br></div></div>