veyepar: Bare-Metal Multicore Performance in a General-Purpose Operating System (Adventures in Ubiquity)

Author(s):	Paul McKenney
Location	OGGB4
Date	jan Thu 15	Days Raw Files
Start	15:40	First Raw Start	15:38
Duration	0:45:00	Offset	0:01:34
End	16:25	Last Raw End	16:30
Chapters	00:00
Total cuts_time	45 min.

http://lca2015.linux.org.au/schedule/30141/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

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

State:

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:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Database, high-performance computing (HPC), and real-time developers have often asked: "Can't you get the kernel out of the way?". Recent adaptive-idle work permits just that: Linux is there when you need it, but if you follow a few simple rules, it is out of your way otherwise.  This approach will provide bare-metal multicore performance and scalability to databases as well as to HPC and real-time applications.

A key part of any project is validation.  Now some people will tell you that Linux-kernel testing doesn't really start until Fengguang Wu subjects your code to his 0-day testing.  Other people will say that testing doesn't really start until Stephen Rothwell does -next integration testing.  Still others claim that testing doesn't really start until your code is accepted into mainline.  Yet other people claim that testing doesn't really start until the distros run their entrprise test suites.  But I am here to tell you that testing doesn't really start until your code is enabled by default by major distros.  At that point, your code becomes ubiquitous, which means that (through no fault of their own!) people start using your code for purposes you had not fully considered, which is usually an excellent way to find new and different corner cases that your code does not yet handle properly.  This talk will describe a few interesting adventures with a few surprising corner cases.

Comment:

production notes