On 04/05 21:27:37, Jerin Jacob wrote:
> -----Original Message-----
> > Date: Tue, 4 Apr 2017 13:47:52 -0500
> > From: Brian Brooks <brian.bro...@arm.com>
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [API-NEXT PATCH v2 00/16] A scalable software scheduler
> > X-Mailer: git-send-email 2.12.2
> > 
> > This work derives from Ola Liljedahl's prototype [1] which introduced a
> > scalable scheduler design based on primarily lock-free algorithms and
> > data structures designed to decrease contention. A thread searches
> > through a data structure containing only queues that are both non-empty
> > and allowed to be scheduled to that thread. Strict priority scheduling is
> > respected, and (W)RR scheduling may be used within queues of the same 
> > priority.
> > Lastly, pre-scheduling or stashing is not employed since it is optional
> > functionality that can be implemented in the application.
> > 
> > In addition to scalable ring buffers, the algorithm also uses unbounded
> > concurrent queues. LL/SC and CAS variants exist in cases where absense of
> > ABA problem cannot be proved, and also in cases where the compiler's atomic
> > built-ins may not be lowered to the desired instruction(s). Finally, a 
> > version
> > of the algorithm that uses locks is also provided.
> > 
> > See platform/linux-generic/include/odp_config_internal.h for further build
> > time configuration.
> > 
> > Use --enable-schedule-scalable to conditionally compile this scheduler
> > into the library.
> 
> This is an interesting stuff.
> 
> Do you have any performance/latency numbers in comparison to exiting scheduler
> for completing say two stage(ORDERED->ATOMIC) or N stage pipeline on any 
> platform?

To give an idea, the avg latency reported by odp_sched_latency is down to half
that of other schedulers (pre-scheduling/stashing disabled) on 4c A53, 16c A57,
and 12c broadwell. We are still preparing numbers, and I think it's worth 
mentioning
that they are subject to change as this patch series changes over time.

I am not aware of an existing benchmark that involves switching between 
different
queue types. Perhaps this is happening in an example app?

> When we say scalable scheduler, What application/means used to quantify
> scalablity??
> 
> Do you have any numbers in comparison to existing scheduler to show
> magnitude of the scalablity on any platform?

Reply via email to