veyepar: Large Pages in Linux

Author(s):	Matthew Wilcox
Location	Arena
Date	jan Thu 16	Days Raw Files
Start	16:40	First Raw Start	error-in-template
Duration	0:45:0	Offset	None
End	17:25	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/45/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Large_Pages_in_Linux.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

Since 2002, Linux has used huge pages to improve CPU performance.  Originally, huge pages supported 2MB pages on x86.  They evolved to support other architectures and, eventually, 1GB pages on x86.  Despite this relative success, the huge page mechanism is not flexible enough to support related hardware features.  One desirable feature is a "medium" large page size (e.g., ARM CPUs support a 64kB page size).  Another is a larger page size (e.g., some network devices support pages as large as 2GB).

In this talk, I will argue that using larger pages to reduce software overhead is as important as enabling hardware optimisations.  I'll talk about the recent patches to improve the performance of larger pages in the page cache.  I'll also talk about patches to bring support for larger pages to normal filesystems.  And I'll talk about some of the downsides of using larger pages, and some of the future limitations of using larger pages.

This talk is for kernel developers and those who are interested in learning more about how some hardware works.  Since these optimisations are supposed to be transparent to user space, no changes should be needed to userspace code to take advantage of them.  End users should only notice their web browsers running faster, their database queries completing faster and their birds being slightly less angry.

Comment:

production notes