Author(s):	Paul McKenney
Location	MCC2
Date	jan Thu 31	Days Raw Files
Start	14:15	First Raw Start	error-in-template
Duration	0:45:00	Offset	None
End	15:00	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2013.linux.org.au/schedule/30201/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf RealTime_Response_on_Multicore_Systems_It_Is_Bigger_Than_I_Thought.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Five years ago, I published a Linux Journal article entitled "SMP and Embedded Real Time" (http://www.linuxjournal.com/article/9361) stating that SMP systems could in fact support real-time workloads. This article was not well-received in all segments of the real-time community, but there are nevertheless quite a few SMP real-time systems in use today offering scheduling latencies of a few tens of microseconds. So perhaps you can imagine my surprise when in early 2012 I received a bug report stating that the Linux kernel's RCU implementation was causing 200-microsecond latency spikes. The root cause? I simply hadn't been thinking big enough. This talk tells the story of the ensuing adventure. markdown
Comment:	production notes