Date:	Wed, 13 Apr 2016 09:57:20 +0100
From:	Juri Lelli <juri.lelli@....com>
To:	"Bill Huey (hui)" <bill.huey@...il.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, Dario Faggioli <raistlin@...ux.it>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Thomas Gleixner <tglx@...utronix.de>,
	KY Srinivasan <kys@...rosoft.com>,
	Amir Frenkel <frenkel.amir@...il.com>,
	Bdale Garbee <bdale@....com>, luca abeni <luca.abeni@...tn.it>
Subject: Re: [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC

[+Luca, as he might be interested]

Hi,

On 11/04/16 22:29, Bill Huey (hui) wrote:
> Hi,
> 
> This a crude cyclic scheduler implementation. It uses SCHED_FIFO tasks
> and runs them according to a map pattern specified by a 64 bit mask. Each
> bit corresponds to an entry into an 64 entry array of
> 'struct task_struct'. This works single core CPU 0 only for now.
> 
> Threads are 'admitted' to this map by an extension to the ioctl() via the
> of (rtc) real-time clock interface. The bit pattern then determines when
> the task will run or activate next.
> 
> The /dev/rtc interface is choosen for this purpose because of its
> accessibilty to userspace. For example, the mplayer program already use
> it as a timer source and could possibly benefit from being sync to a
> vertical retrace interrupt during decoding. Could be an OpenGL program
> needing precisely scheduler support for those same handling vertical
> retrace interrupts, low latency audio and timely handling of touch
> events amognst other uses.
> 

Interesting! I read doc patch and only skimmed through the others, but
I seem to already have a general type of question.

Since you seem familiar with SCHED_DEADLINE [1] (you refer to deadline
scheduling in the doc patch and Dario is in CC :-)), what do you think
is wrong with just use that for this type of workloads?

AFAIK, mplayer (like) type of workloads already play well with deadline
scheduling, and SCHED_DEADLINE is mainline and actively maintained and
developed [2].

Best,

- Juri

[1] http://onlinelibrary.wiley.com/doi/10.1002/spe.2335/abstract
[2] http://events.linuxfoundation.org/sites/events/files/slides/SCHED_DEADLINE-20160404.pdf

> There is also a need for some kind of blocking/yielding interface that can
> return an overrun count for when the thread utilizes more time than
> allocated for that frame. The read() function in rtc is overloaded for this
> purpose and reports overrun events. Yield functionality has yet to be fully
> tested.
> 
> I apologize for any informal or misused of terminology as I haven't fully
> reviewed all of the academic literature regarding these kind of schedulers.
> I welcome suggestions and corrects etc
> 
> Special thanks to includes...
> 
> Peter Ziljstra (Intel), Steve Rostedt (Red Hat), Rik van Riel (Red Hat) for
> encouraging me to continue working in the Linux kernel community and being
> generally positive and supportive.
> 
> KY Srinivasan (formerly Novell now Microsoft) for discussion of real-time
> schedulers and pointers to specifics on that topic. It was just a single
> discussion but was basically the inspiration for this kind of work.
> 
> Amir Frenkel (Palm), Kenneth Albanowski (Palm), Bdale Garbee (HP) for the
> amazing place that was Palm, Kenneth for being a co-conspirator with this
> scheduler. This scheduler was inspired by performance work that I did
> at Palm's kernel group along with discussions with the multimedia team
> before HP kill webOS off. Sad and infuriating moment.
> 
> Maybe, in a short while, the community will understand the value of these
> patches for -rt and start solving the general phenomenon of high performance
> multi-media and user interactivity problems more properly with both a
> scheduler like this and -rt shipped as default in the near future.
> 
> [Also, I'd love some kind of sponsorship to continue what I think is
> critical work versus heading back into the valley]
> 
> ---
> 
> Bill Huey (hui) (12):
>   Kconfig change
>   Reroute rtc update irqs to the cyclic scheduler handler
>   Add cyclic support to rtc-dev.c
>   Anonymous struct initialization
>   Task tracking per file descriptor
>   Add anonymous struct to sched_rt_entity
>   kernel/userspace additions for addition ioctl() support for rtc
>   Compilation support
>   Add priority support for the cyclic scheduler
>   Export SCHED_FIFO/RT requeuing functions
>   Cyclic scheduler support
>   Cyclic/rtc documentation
> 
>  Documentation/scheduler/sched-cyclic-rtc.txt | 468 ++++++++++++++++++++
>  drivers/rtc/Kconfig                          |   5 +
>  drivers/rtc/class.c                          |   3 +
>  drivers/rtc/interface.c                      |  23 +
>  drivers/rtc/rtc-dev.c                        | 161 +++++++
>  include/linux/init_task.h                    |  18 +
>  include/linux/rtc.h                          |   3 +
>  include/linux/sched.h                        |  15 +
>  include/uapi/linux/rtc.h                     |   4 +
>  kernel/sched/Makefile                        |   1 +
>  kernel/sched/core.c                          |  13 +
>  kernel/sched/cyclic.c                        | 620 +++++++++++++++++++++++++++
>  kernel/sched/cyclic.h                        |  86 ++++
>  kernel/sched/cyclic_rt.h                     |   7 +
>  kernel/sched/rt.c                            |  41 ++
>  15 files changed, 1468 insertions(+)
>  create mode 100644 Documentation/scheduler/sched-cyclic-rtc.txt
>  create mode 100644 kernel/sched/cyclic.c
>  create mode 100644 kernel/sched/cyclic.h
>  create mode 100644 kernel/sched/cyclic_rt.h
> 
> -- 
> 2.5.0
> 

Powered by blists - more mailing lists