XS Boston 2008 Guest Spinning

•

0 likes•882 views

The Linux Foundation

Thomas Friebel: Preventing Guests from Spinning Around - Video

Technology Business

Preventing Guests from Spinning Around

How to Deal with Lock-Holder Preemption
Thomas Friebel

June 23, 2008

Spinlock Basics

Spinlocks wait actively as opposed to sleeping locks

Used for short critical sections

2 How to Deal with Lock-Holder Preemption

Spinlock Wait Times – Kernbench

3 How to Deal with Lock-Holder Preemption

Spinlock Wait Times – Kernbench

4 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

5 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

6 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

7 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

8 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

9 How to Deal with Lock-Holder Preemption

Spinlocks and Virtualization

10 How to Deal with Lock-Holder Preemption

Is lock-holder preemption problematic?

11 How to Deal with Lock-Holder Preemption

Kernbench in a Guest

12 How to Deal with Lock-Holder Preemption

Kernbench vs. 'while(true)'

13 How to Deal with Lock-Holder Preemption

Time, not Times

14 How to Deal with Lock-Holder Preemption

And in Numbers?

guest time time spent spinning
[s] [s] [%]
single kernbench 109.0 0.2 0.2%
kernbench vs while(1) 117.3 9.0 7.6%
difference 7.6%

15 How to Deal with Lock-Holder Preemption

What can we do about it?

16 How to Deal with Lock-Holder Preemption

Dealing with lock-holder preemption

LHP avoidance
 No spinlock held in userspace
 Idea: Avoid preempting guest in kernel space
 Postpone guest switch to kernel exit
 Problem: extraordinary long critical sections, e.g.
Apache using sendfile()

Helping locks
 Instead of busy waiting, switch to preempted lock-
holder
 Problem: finding the preempted lock-holder

17 How to Deal with Lock-Holder Preemption

Helping locks: Ingredients

1) Guest kernel: new 'yield' hypercall when waiting
unusually long
Modify spinlock loop
●

2) Reasonable threshold for 'unusually long'
Histograms help
●

3) Selecting which VCPU to switch to

18 How to Deal with Lock-Holder Preemption

Threshold: Upper boundary

19 How to Deal with Lock-Holder Preemption

Threshold: Lower boundary

20 How to Deal with Lock-Holder Preemption

Scheduling Strategy

Good choices:
 VCPUs of the same VM to make progress locally
 (Potential) preempted lock-holders
 Cache-„near“ VCPUs

Neither/nor:
 VCPUs in user space

Bad choices:
 VCPUs which yielded recently

21 How to Deal with Lock-Holder Preemption

What about performance?

22 How to Deal with Lock-Holder Preemption

Histogram with 'yield' hypercall

23 How to Deal with Lock-Holder Preemption

Performance

wall clock guest time time spent spinning
[s] [s] [s] [%]
LHP 34.8 117.3 9.0 7.6%
yield 33.5 108.4 0.0 0.0%
difference -3.9% -7.6% -7.6%

24 How to Deal with Lock-Holder Preemption

Efficiency

25 How to Deal with Lock-Holder Preemption

Efficiency

26 How to Deal with Lock-Holder Preemption

Efficiency

27 How to Deal with Lock-Holder Preemption

Efficiency

28 How to Deal with Lock-Holder Preemption

Efficiency

29 How to Deal with Lock-Holder Preemption

Efficiency

30 How to Deal with Lock-Holder Preemption

Efficiency

31 How to Deal with Lock-Holder Preemption

Efficiency

117 sec
×7.6 % = 3.7 %
117 sec 126 sec

Real result of 3.9% is reasonable
➔

Highly efficient
➔

32 How to Deal with Lock-Holder Preemption

FIFO ticket spinlocks

33 How to Deal with Lock-Holder Preemption

FIFO ticket spinlocks

Next ticket in dispenser: queue tail

„Now serving“ display at counter: queue head

Lock: atomic( ticket = tail++ ); while ( head != ticket );

Unlock: atomic( head++ );

34 How to Deal with Lock-Holder Preemption

FIFO ticket spinlocks

35 How to Deal with Lock-Holder Preemption

Ticket locks and virtualization

wall clock guest time time spent spinning
[s] [s] [s] [%]
LHP 2825.1 22434.2 22270.4 99.3%

36 How to Deal with Lock-Holder Preemption

Ticket locks and virtualization

wall clock guest time time spent spinning
[s] [s] [s] [%]
LHP 2825.1 22434.2 22270.4 99.3%
yield 34.1 123.6 6.6 5.4%

37 How to Deal with Lock-Holder Preemption

Conclusion

Lock-holder preemption quite serious:
7.6% guest time wasted

Helping locks:
3.9% system performance improvement!
(Amdahl's law explains why)

New ticket spinlocks:
30 secs kernbench takes 45 minutes

Helping locks help here, too

38 How to Deal with Lock-Holder Preemption

Similar to XS Boston 2008 Guest Spinning

This slides were presented at the 9th ACM SIGPLAN/SIGOPS international conference on Virtual Execution Environments (VEE '13). When executing inside a virtual machine environment, OS level synchronization primitives are faced with significant challenges due to the scheduling behavior of the underlying virtual machine monitor. Operations that are ensured to last only a short amount of time on real hardware, are capable of taking considerably longer when running virtualized. This change in assumptions has significant impact when an OS is executing inside a critical region that is protected by a spinlock. The interaction between OS level spinlocks and VMM scheduling is known as the Lock Holder Preemption problem and has a significant impact on overall VM performance. However, with the use of ticket locks instead of generic spinlocks, virtual environments must also contend with waiters being preempted before they are able to acquire the lock. This has the effect of blocking access to a lock, even if the lock itself is available. We identify this scenario as the Lock Waiter Preemption problem. In order to solve both problems we introduce Preemptable Ticket spinlocks, a new locking primitive that is designed to enable a VM to always make forward progress by relaxing the ordering guarantees offered by ticket locks. We show that the use of Preemptable Ticket spinlocks improves VM performance by 5.32X on average, when running on a non paravirtual VMM, and by 7.91X when running on a VMM that supports a paravirtual locking interface, when executing a set of microbenchmarks as well as a realistic e-commerce benchmark.

Preemptable ticket spinlocks: improving consolidated performance in the cloud

Jiannan Ouyang, PhD

Meltdown & spectre

Sergio Shevchenko

Meltdown & Spectre

Marco Cipriano

Mingbo Zhang, Rutgers University Saman Zonouz, Rutgers University Time-of-check-to-time-of-use (TOCTOU) also known as “race condition” or “double fetch” is a long standing problem. Since memory read/write is so common an operation, it barely triggers no security mechanisms. We leverage a CPU feature called SMAP(Supervisor Mode Access Prevention) to efficiently monitor the events of kernel accessing user-mode memory. When user pages being accessed by kernel, our mitigation kicks in and protect them against further modifications from other user-mode threads. We also leverage the same CPU feature to find double fetch errors in kernel modules. A simple hypervisor is used to confine a system wide CPU feature such as SMAP to particular process.

BlueHat v18 || A mitigation for kernel toctou vulnerabilities

BlueHat Security Conference

Distributed Lock Manager

Hao Chen

Sangam 18 - Database Development: Return of the SQL Jedi

Connor McDonald

Need for Async: Hot pursuit for scalable applications

Konrad Malawski

An Introduction to Locks in Go

Yu-Shuan Hsieh

Talk held at DevOps Gathering 2019 in Bochum on 2019-03-13. Abstract: This talk will address one of the most common challenges of organizations adopting Kubernetes on a medium to large scale: how to keep cloud costs under control without babysitting each and every deployment and cluster configuration? How to operate 80+ Kubernetes clusters in a cost-efficient way for 200+ autonomous development teams? This talk provides insights on how Zalando approaches this problem with central cost optimizations (e.g. Spot), cost monitoring/alerting, active measures to reduce resource slack, and automated cluster housekeeping. We will focus on how to ingrain cost efficiency in tooling and developer workflows while balancing rigid cost control with developer convenience and without impacting availability or performance. We will show our use case running Kubernetes on AWS, but all shown tools are open source and can be applied to most other infrastructure environments.

Ensuring Kubernetes Cost Efficiency across (many) Clusters - DevOps Gathering...

Henning Jacobs

Talk given at JAX DevOps London on 2019-05-15 Kubernetes has the concept of resource requests and limits. Pods get scheduled on the nodes based on their requests and optionally limited in how much of the resource they can consume. Understanding and optimizing resource requests/limits is crucial both for reducing resource "slack" and ensuring application performance/low-latency. This talk shows our approach to monitoring and optimizing Kubernetes resources for 90+ clusters to achieve cost-efficiency and reducing impact for latency-critical applications. All shown tools are open source and can be applied to most Kubernetes deployments. Topics covered in the talk include: understanding resource requests and limits, cgroups and CFS quota behavior, contributing factors to cluster costs (in public clouds), and best practices for managing Kubernetes resources.

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency

Henning Jacobs

Talk given at JAX DevOps London on 2019-05-15. Kubernetes has the concept of resource requests and limits. Pods get scheduled on the nodes based on their requests and optionally limited in how much of the resource they can consume. Understanding and optimizing resource requests/limits is crucial both for reducing resource "slack" and ensuring application performance/low-latency. This talk shows our approach to monitoring and optimizing Kubernetes resources for 90+ clusters to achieve cost-efficiency and reducing impact for latency-critical applications. All shown tools are open source and can be applied to most Kubernetes deployments. Topics covered in the talk include: understanding resource requests and limits, cgroups and CFS quota behavior, contributing factors to cluster costs (in public clouds), and best practices for managing Kubernetes resources.

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latenc...

Henning Jacobs

The research work that I describe in this dissertation is concerned with the problem of shared-memory synchronization in large-scale programs. The difficulties of developing fine-grained lock-based synchronization are well-known and many researchers have argued for the need of alternative approaches. Simply put, the main goal of my work is to provide an efficient alternative to such approaches. My proposal is based on Software Transactional Memory (STM) and I implemented it in a well-known STM framework for Java---Deuce STM. To that end I propose a new approach that significantly lowers the overhead caused by an STM in large-scale programs for which only a small fraction of the memory is under contention. My solution combines two novel optimization techniques in a synergistic way, allowing us to get, for the first time, performance with an STM that rivals the performance of the best lock-based approaches in some of the more challenging benchmarks. My approach and experimental results show that STMs may be the first efficient alternative to locks for shared-memory synchronization in real-world--sized applications.

opt-mem-trx

Miguel Gamboa

Mes conteneurs JVM sont en prod, oups ils se font oomkill, oups le démarrage traîne en longueur, oups ils sont lent en permanence. Nous avons vécu ces situations. Ces problèmes émergent parce qu’un conteneur est par nature un milieu restreint. Sa configuration a un impact sur le process Java, cependant ce process a lui aussi des besoins pour fonctionner. Il y a un espace entre la heap Java et le RSS : c’est la mémoire off-heap et elle se décompose en plusieurs zones. À quoi servent-elles ? Comment les prendre en compte ? La configuration du CPU impacte la JVM sur divers aspects : Quelles sont les influences entre le GC et le CPU ? Que choisir entre la rapidité ou la consommation CPU au démarrage ? Au cours de cette université nous verrons comment diagnostiquer, comprendre et remédier à ces problèmes.

Devoxx Fr 2022 - Remèdes aux oomkill, warm-ups, et lenteurs pour des conteneu...

Jean-Philippe BEMPEL

ioDrive de benchmarking 2011 1209_zem_distribution

Masahito Zembutsu

MSc_thesis_defence

Athanasios Karapatis

Artificial intelligence (AI) has already been attracting the attention of deep tech investors for some years. The reasons why are clear. In its ‘Sizing The Prize’ analysis of artificial intelligence (AI), PwC forecast that AI will contribute $15.7 trillion to the global economy by 2030, with the ‘AI boost’ available to most national economies being approximately 26%. But what investors often overlook is that AI is not singular. Many individual components must work together to create AI. At its core artificial intelligence consists essentially of detecting statistical patterns in signals with many dimensions, such as analysis of audio frequencies (voice recognition) or high-resolution images (face recognition). The repetition of this search in order to detect these patterns is the basis of artificial intelligence. There are usually three components to AI: First, given a data set, learning what the patterns are. Second, building a model that can detect these patterns. Third, model deployment to the target environment. Traditionally, data mining or learning was done by experts in the matter who would develop some sort of classifier or detector based on certain features, and then try to see their correlations. This process was tedious and time consuming. https://klepsydra.com/cityam-ai-on-the-edge/

Smallsat 2021

klepsydratechnologie

Psychtoolbox (PTB) practical course by Volodymyr B. Bogdanov, Lyon/Kyiv 2018...

Volodymyr Bogdanov

This is the second edition of the story about how we struggled to implement strict latency requirements in a service implemented with Java and how we managed to do that. The most common latency contributors are an in-process locking, thread scheduling, I/O, algorithmic inefficiencies and, of course, garbage collector. I will share our experience of dealing with the causes. And tell what you can do to prevent them from affecting the production.

On the way to low latency (2nd edition)

Artem Orobets

"Invidi ad decisioning engine needs semi-realtime feedback on the performance of the ad campaigns it runs. In the heart of this feedback loop there is a service that aggregates 1B+ daily ad tracking events and serves campaign performance time series to the ad decisioning engine over http. Recently we successfully rewrote it as a pure Kafka Streams application with all data being stored in Kafka and served via Interactive Queries. The experience was surprisingly not straightforward and we had to trade off some of the simplicity of our processing topology to increase scalability and lower resource consumption. In this talk we plan to go over the system architecture and share the issues we faced and how we solved them. Here are some highlights: - The distribution of our aggregation keys is very skewed, so early repartitioning resulted in poor scalability. To mitigate this issue we used a scatter-gather approach avoiding repartitioning and combining results in IQ. To minimize memory consumption we had to combine the above approach with pre-aggregating events before re-partitioning in a lambda-architecture style. - Due to multiple stores sharing buffer memory we had to resort to manually deleting entries in our live windowed stores to avoid premature flushing of the aggregates due to cache thrashing. - We had to implement our own in-memory windowed store to increase IQ performance We hope that our findings will be helpful to a wider audience. We also plan to file and fix the issues we discovered in the near future."

Aggregating Ad Events with Kafka Streams and Interactive Queries at Invidi

HostedbyConfluent

Similar to XS Boston 2008 Guest Spinning (19)

Preemptable ticket spinlocks: improving consolidated performance in the cloud

Meltdown & spectre

Meltdown & Spectre

BlueHat v18 || A mitigation for kernel toctou vulnerabilities

Distributed Lock Manager

Sangam 18 - Database Development: Return of the SQL Jedi

Need for Async: Hot pursuit for scalable applications

An Introduction to Locks in Go

Ensuring Kubernetes Cost Efficiency across (many) Clusters - DevOps Gathering...

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latenc...

opt-mem-trx

Devoxx Fr 2022 - Remèdes aux oomkill, warm-ups, et lenteurs pour des conteneu...

ioDrive de benchmarking 2011 1209_zem_distribution

MSc_thesis_defence

Smallsat 2021

Psychtoolbox (PTB) practical course by Volodymyr B. Bogdanov, Lyon/Kyiv 2018...

On the way to low latency (2nd edition)

Aggregating Ad Events with Kafka Streams and Interactive Queries at Invidi

More from The Linux Foundation

Static partitioning is used to split an embedded system into multiple domains, each of them having access only to a portion of the hardware on the SoC. It is key to enable mixed-criticality scenarios, where a critical application, often based on a small RTOS, runs alongside a larger non-critical app, typically based on Linux. The two domains cannot interfere with each other. This talk will explain how to use Xen for static partitioning. It will introduce dom0-less, a new Xen feature written for the purpose. Dom0-less allows multiple VMs to start at boot time directly from the Xen hypervisor, decreasing boot times drastically. It makes it very easy to partition the system without virtualization overhead. Dom0 becomes unnecessary. This presentation will go into details on how to setup a Xen dom0-less system. It will show configuration examples and explain device assignment. The talk will discuss its implications for latency-sensitive and safety-critical environments.

ELC2019: Static Partitioning Made Simple

The Linux Foundation

TrenchBoot is a cross-community OSS integration project for hardware-rooted, late launch integrity of open and proprietary systems. It provides a general purpose, open-source DRTM kernel for measured system launch and attestation of device integrity to trust-centric access infrastructure. TrenchBoot closes the UEFI Measurement Gap and reduces the need to trust system firmware. This talk will introduce TrenchBoot architecture and a recent collaboration with Oracle to launch the Linux kernel directly with Intel TXT or AMD SVM Secure Launch. It will propose mechanisms for integrating the Xen hypervisor into a TrenchBoot system launch. DRTM-enabled capabilities for client, server and embedded platforms will be presented for consideration by the Xen community.

XPDDS19: How TrenchBoot is Enabling Measured Launch for Open-Source Platform ...

The Linux Foundation

Artem will briefly cover what has been done since the first talk on Xen in Automotive domain back in 2013, what is going on now and what is still missing for broad adaptation of Xen in vehicles. The following topics will be covered: Embedded/automotive features of Xen Collaboration with AGL and GENIVI organizations for standardization Efforts on Functional Safety compliance Artem will also go over typical automotive use scenarios for Xen which may not be the same as generic computing use of hypervisor.

XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...

The Linux Foundation

XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Op...

The Linux Foundation

In recent years unikernels have shown immense performance potential (e.g., boot times of only a few ms, image sizes of only hundreds of KBs).The fundamental drawback of unikernels is that they require that applications be manually ported to the underlying minimalistic OS, needing both expert work and often considerable amount of time. The Unikraft project provides a unikernel code base and build system that significantly simplifies the building of unikernels. In addition to support for a number CPU architectures, languages and frameworks, Unikraft provides debugging and tracing features that are generally sorely missing from unikernel projects. In this talk we will talk about these features, show a set of preliminary performance numbers, and provide a roadmap for the project's future.

XPDDS19 Keynote: Unikraft Weather Report

The Linux Foundation

XPDDS19 Keynote: Secret-free Hypervisor: Now and Future - Wei Liu, Software E...

The Linux Foundation

This talk will introduce Dom0-less: a new way of using Xen to build mixed-criticality solutions. Dom0-less is a Xen feature that adds a novel approach to static partitioning based on virtualization. It allows multiple domains to start at boot time directly from the Xen hypervisor, decreasing boot times dramatically. Xen userspace tools, such as xl and libvirt, become optional. Dom0-less extends the existing device tree based Xen boot protocol to cover information required by additional domains. Binaries, such as kernels and ramdisks, are loaded by the bootloader (u-boot) and advertised to Xen via new device tree bindings. The audience will learn how to use Dom0-less to partition the system. Uboot and device tree configuration details will be explained to enable the audience to get the most out of this feature. The talk will include a status update and details on future plans.

XPDDS19 Keynote: Xen Dom0-less - Stefano Stabellini, Principal Engineer, Xilinx

The Linux Foundation

As the number of contributions grow, reviewer bandwidth becomes a bottleneck; and maintainers are always asking for more help. However, ultimately maintainers must at least Ack every patch that goes in; so if you're not a maintainer, how can you contribute? Why should anyone care about your opinion? This talk will try to lay out some advice and guidelines for non-maintainers, for how they can do code review in a way which will effectively reduce the load on maintainers when they do come to review a patch.

XPDDS19 Keynote: Patch Review for Non-maintainers - George Dunlap, Citrix Sys...

The Linux Foundation

This talk is a follow-up to our Summit 2017 presentation in which we covered our plans for Intel VMFUNC and #VE, as well as related use-cases. This year, we will provide a report on what we have accomplished in Xen 4.12, and what remains to be addressed. We will also give a brief status update of VMI on AMD hardware. The session will end with some real-world numbers of the Hypervisor Introspection solution running on Citrix Hypervisor 8.0 with #VE enabled.

XPDDS19: Memories of a VM Funk - Mihai Donțu, Bitdefender

The Linux Foundation

Safety certification is one of the essential requirements for software to be used in highly regulated industries. Besides technical and compliance issues (such as ISO 26262 vs IEC 611508) transitioning an existing project to become more easily safety certifiable requires significant changes to development practices within an open source project. In this session, we will lay out some challenges of making safety certification achievable in open source and the Xen Project. We will outline the process the Xen Project has followed thus far and highlight lessons learned along the way. The talk will primarily focus on necessary process, tooling changes and community challenges that can prevent progress. We will be offering an in-depth review of how Xen Project is approaching this challenging goal and try to derive lessons for other projects and contributors.

OSSJP/ALS19: The Road to Safety Certification: Overcoming Community Challeng...

The Linux Foundation

Safety certification is one of the essential requirements for software to be used in highly regulated industries. The Xen Project, a secure and stable hypervisor that is used in many different markets, has been exploring the feasibility of building safety certified products on top of Xen for a year, looking at key aspects of its code base and development practices. In this session, we will lay out the motivation and challenges of making safety certification achievable in open source and the Xen Project. We will outline the process the project has followed thus far and highlight lessons learned along the way. The talk will cover technical enablers, necessary process and tooling changes and community challenges offering an in-depth review of how Xen Project is approaching this exciting and and challenging goal.

OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...

The Linux Foundation

2018 saw fundamental shifts in security boundaries which were previously taken for granted. A lot of work has been done in the past 2 years, and largely in secret under embargo, but there is plenty more work to be done to strengthen the existing mitigations and to try to recover some performance without reopening security holes. This talk will look at speculative execution sidechannels, the work which has already been done to mitigate the security holes, and future work which hopes to bring some improvements.

XPDDS19: Speculative Sidechannels and Mitigations - Andrew Cooper, Citrix

The Linux Foundation

The Arm architecture provides a set of guidelines that any software should abide by when accessing the memory with MMU off and update page-tables. Failing to do so may result in getting TLB conflicts or breaking coherency. In a previous talk ("Keeping coherency on Arm"), we focused on updating safely the stage-2 (aka P2M) page-tables. This talk will focus on the boot code and Xen memory management. During this session, we will introduce some of the guidelines and when they should be used. We will also discuss how Xen boot sequence needs to be reworked to avoid breaking the guidelines.

XPDDS19: Keeping Coherency on Arm: Reborn - Julien Grall, Arm ltd

The Linux Foundation

For many years the QEMU codebase has contained PV backends for Xen guests, giving them paravirtual access to storage, network, keyboard, mouse, etc. however these backends have not been configurable as QEMU devices as their implementation did not fully adhere to the QEMU Object Model (QOM). Particularly the PV storage backend not using proper QOM devices, or qdevs, meant that the QEMU block layer needed to maintain legacy code that was cluttering up the source. This was causing push-back from the maintainers who did not want to accept any patches relating to that Xen backend until it was 'qdevified'. In this talk, I'll explain the modifications I made to QEMU to achieve 'qdevification' of the PV storage backend, how compatibility with the libxl toolstack was maintained, and what the next steps in both QEMU and libxl development should be.

XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant...

The Linux Foundation

PCI is a local computer bus for attaching hardware devices in a computer, and is the main peripheral bus on modern x86 systems. As such, having a proper way to emulate it is crucial for Xen to be able to expose both fully emulated devices or passthrough devices to guests. This talk will focus on the current status of PCI emulation in Xen, how and where it is used, what are its main limitations and future plans to improve it in order to be more robust and modular.

XPDDS19: Status of PCI Emulation in Xen - Roger Pau Monné, Citrix Systems R&D

The Linux Foundation

XPDDS19: [ARM] OP-TEE Mediator in Xen - Volodymyr Babchuk, EPAM Systems

The Linux Foundation

Xen is a very powerful hypervisor with a talented and diverse developers community. Despite the fact it's almost everywhere (from the Cloud to the embedded world), it can be difficult to set up and manage as a system administrator. General purpose distros have Xen packages, but that's just a start in your Xen journey: you need some tooling and knowledge to have a working and scalable platform. XCP-ng was built to overcome those issues: by bringing Xen to the masses with a fully turnkey distro with Xen as its core. It's the logical sequel to the XCP project, with a community focus from the start. We'll see how it happened, what we did, and what's next. Finally, we'll see the impact of XCP-ng on the Xen Project.

XPDDS19: Bringing Xen to the Masses: The Story of Building a Community-driven...

The Linux Foundation

XPDDS19: Will Robots Automate Your Job Away? Streamlining Xen Project Contrib...

The Linux Foundation

High level toolstacks for server and cloud virtualization are very mature with large communities using and supporting them. Client virtualization is a much more niche community with unique requirements when compared to those found in the server space. In this talk, we’ll introduce a client virtualization toolstack for Xen (redctl) that we are using in Redfield, a new open-source client virtualization distribution that builds upon the work done by the greater virtualization and Linux communities. We will present a case for maturing libxl’s Go bindings and discuss what advantages Go has to offer for high level toolstacks, including in the server space.

XPDDS19: Client Virtualization Toolstack in Go - Nick Rosbrook & Brendan Kerr...

The Linux Foundation

Today Xen is scheduling guest virtual cpus on all available physical cpus independently from each other. Recent security issues on modern processors (e.g. L1TF) require to turn off hyperthreading for best security in order to avoid leaking information from one hyperthread to the other. One way to avoid having to turn off hyperthreading is to only ever schedule virtual cpus of the same guest on one physical core at the same time. This is called core scheduling. This presentation shows results from the effort to implement core scheduling in the Xen hypervisor. The basic modifications in Xen are presented and performance numbers with core scheduling active are shown.

XPDDS19: Core Scheduling in Xen - Jürgen Groß, SUSE

The Linux Foundation

More from The Linux Foundation (20)