intro to virtualization (part 3)

24
Wrap-up Basics of Computing ( Software Threads) As Needed to Understand OS Virtualization

Upload: kiru-sengal

Post on 14-Jan-2017

28 views

Category:

Engineering


7 download

TRANSCRIPT

Page 1: Intro to Virtualization (Part 3)

Wrap-up Basics of Computing( Software Threads)

As Needed to Understand OS Virtualization

Page 2: Intro to Virtualization (Part 3)

What we know: Abstract view of Computing

Process 2

Process 3

Process 4

Process N

Operating System Kernel

Process 1

System Call Interface

Scheduler

DriversFile system services

Memory management

CPU management

This diagram is accurate, but can be refined to be more detailed in cases where a process is made up of multiple “software threads”

Page 3: Intro to Virtualization (Part 3)

Every lcore

Memory

Registers

PC

Program 1

Program 2

Program 2

Kernel

Other Logic

(e.g. ALU)

What we know: Multiprogramming allows each lcore to run multiple programs concurrently

Page 4: Intro to Virtualization (Part 3)

What we knew: MultiProcessing + Simultaneous MultiThreading + MultiProgramming:

Logical Core

Logical Core

Logical Core

Logical Core

Socket / CPU

Core

Core

LCORE1

LCORE2

LCORE3

LCORE4

Page 5: Intro to Virtualization (Part 3)

Review: What exactly “is” a running process?

Data

CodeRegisters

PC

Other Logic

(e.g. ALU)

Execution state (PC, registers, etc.)

Page Table, which lives in Kernel’s memory, but is loaded into TLB when process runs

Data and Code blocks in Virtual Memory

Memory region

Running (and reading instructions from CODE region)

CPU translates instruction addresses to virtual memory addresses via a page table:

Page 6: Intro to Virtualization (Part 3)

Where do we SAVE these things when processblocks or is context switched out?

Memory

Program 1

Program 2

Program 3

Kernel

Every lcore

Registers

PC

Other Logic

(e.g. ALU)

Execution state (PC, registers, etc.)

Page Table (which is cached in CPU as TLB)

Execution state (PC, Registers) Saved in kernel’s memory

Page 7: Intro to Virtualization (Part 3)

Where do we save the Page Table and Memory Region of Process?

• Page Table “already” lives in the Kernel’s memory structures (though it’s cached into a TLB near/in CPU when process is loaded).So all we need to do is make sure any updates that were made to TLB are updated into Page Table also.

• Memory Region of a Process can stay as is, because all processes co-exist in RAM+SWAP at same time (remember: this makes multiprogramming fast).

Page 8: Intro to Virtualization (Part 3)

Somewhere in Kernel’s Memory … Somewhat like this…

Kernel

P1’s Execution

State

P1’s Page Table

P2’s Page Table

P1’s Page Table

P2’s Execution

State

P3’s Execution

State

Has Program Counter (i.e., address in code where the program when “paused”) and registers (i.e., contents of intermediate variables used within CPU) it last had when it was saved/interrupted/context-switched.

Other stuff in Kernel’s memory

Page 9: Intro to Virtualization (Part 3)

Multiple Instances of Same Program

• SCENARIO:We have a web server that serves HTTP requests. The process is called httpd.

• Early versions of httpd might have run as a single process, and served http requests to any browser that connected to it.

• But eventually, we wanted a web server to service > 1 connection concurrently. How do we do this?

Page 10: Intro to Virtualization (Part 3)

FORK: Multiple httpd Processes• Run multiple httpd processes• 1 to listen for new connections on port 80/443• For each new connections it accepts on port 80/443, it

“forks” (creates another copy) of itselfThis creates an essentially identical httpd process

• E.g., Assume 2 browsers have connected to a website running httpd, there will be at one point 3 httpd processes running concurrently(1 for listening to new connections, 2 processes serving the 2 browsers)

• NOTE: This feature is possible with MultiProgramming (does not require software threads) …

Page 11: Intro to Virtualization (Part 3)

Multiple Processes from Same Executable

Core/Processor

Memory

Registers

PC

Program 1

Program 2

HTTPD

Kernel

Other Logic

(e.g. ALU)

HTTPD

HTTPD

Works, but… can we do this more efficiently?

Page 12: Intro to Virtualization (Part 3)

Software Multithreading

• In previous example, WHY have 3 processes running with the same CODE residing in memory?

• Why not have multiple execution states, where each of these states have program counters that point into the same CODE memory region?

• Analogy:Instead of creating 3 elves that get instructions to build same toy from 3 different IDENTICAL instruction sheets, why not have the 3 elves read off the same instruction sheet?

Page 13: Intro to Virtualization (Part 3)

Software Threads:Different Execution Contexts within Same Process (i.e., same memory region, page table)

Core/Processor Memory

Registers

PC = 0xE4BA

Program 1

Program 2

HTTPD

Kernel

Other Logic

(e.g. ALU)

Single Thread

Single Thread

ThreeThreads

QUESTION: Assume the above running software thread gets context switched out exactly at shown state (same PC), can we then tell which thread was running??The above picture proves that ONE of the three threads of HTTPD process is running (because PC refers to HTTPD’s core area). BUT it is still unclear which thread…

Page 14: Intro to Virtualization (Part 3)

ZOOM into Kernel’s Memory Structures

P1’s Execution

State

P1’s Page Table

P2’s Page Table

P1’s Page Table

P2’s Execution

State

HTTPD Thread 1 Execution

State

HTTPD Thread 2 Execution

State

HTTPD Thread 3 Execution

StatePC PC PC

PC PC

PC = 0xE39C

PC = 0xE4BA

PC = 0xE219

Zooming into the

Program Counters of

the HTTPD threads

• 3 software threads of HTTPD process have different execution states

• Regardless, the entire HTTPD process only has one common page table (because process only has 1 memory region, so there needs to only be 1 table to do address translations)

Page 15: Intro to Virtualization (Part 3)

DATA REGION of PROCESS’s MEMORY• Made up of GLOBAL memory that is shared by all

software threads of process• And also made up of LOCAL memory that is used by

each software thread.This local memory is used for many things, including to keep track of “function call state”

(really a part of the execution state)• Even if a process is made up of 1 thread (the default

situation), it still has local memory for function call state and global memory, but it was not that important to mention this earlier before introduction of software threads.

Page 16: Intro to Virtualization (Part 3)

HTTPD’s (1 process with 3 software threads) Memory Region:

Memory

Program 1

Program 2

HTTPD

Kernel

ZOOMLocal Data Memory for Thread 3

Local Data Memory for Thread 2

Local Data Memory for Thread 1

Global Data Memory for Entire Process

Code Memory (instructions) pointed to by PC of all threads of this process

Page 17: Intro to Virtualization (Part 3)

WARM AND FUZZY DIAGRAM THAT IS OFTEN PRESENTED TO EXPLAIN THREADS…

Page 18: Intro to Virtualization (Part 3)

WARM AND FUZZY DIAGRAM THAT IS OFTEN PRESENTED TO EXPLAIN THREADS…

Page 19: Intro to Virtualization (Part 3)

WARM AND FUZZY DIAGRAM THAT IS OFTEN PRESENTED TO EXPLAIN THREADS…

Page 20: Intro to Virtualization (Part 3)

Advantage of Software Threads (vs. multiple processes running same

executable/code)

• Software threads A.k.a. “LIGHT-WEIGHT” processes• Less wasted virtual memory (shared CODE and

GLOBAL DATA memory regions)• Share a page table too – Makes contexts switches between threads of same

process very fast (no need to load a new page table into TLB)

• Easier communication (shared GLOBAL DATA allows for some faster communication)

• Faster to create new threads vs. new process (fork)

Page 21: Intro to Virtualization (Part 3)

What we know: MultiProcessing + Simultaneous MultiThreading + MultiProgramming + Software MultiThreading

Logical Core

Logical Core

Logical Core

Logical Core

Socket / CPU

Core

Core

LCORE1

LCORE2

LCORE3

LCORE4NOW we know these purple regions of time are really periods when unique software threads are executing.

Page 22: Intro to Virtualization (Part 3)

OS Scheduling• NOW we know:– In modern computers, the operating system is

really scheduling:• Software threads onto logical cores• Each logical core has:

– 1 software thread running on it– While several software threads are waiting on that lcore’s

READY QUEUE to run on it

• This diagram really refers to software threads:

Page 23: Intro to Virtualization (Part 3)

Pinning / Isolation• By default any software thread can land on ready queue of any logical

core• To modify this behavior, you can provide RULES that pin software

thread(s) or isolate logical core(s)

• Pinning software threads:– Reducing the set of logical cores that a software thread is allowed to be

scheduled onto– E.g., via “taskset” command

or sched_setaffinity system call• Isolation of logical cores:

– Isolating a logical core REMOVES it from general pool for which threads can be scheduled on, EXCEPT when a thread is specifically pinned to that logical core

– E.g., via “isolcpus” kernel boot parameter (check /boot/grub*/grub*.cfg)

Page 24: Intro to Virtualization (Part 3)

DEMO

• Sorry nothing to do with virtualization, but we will use a VM (treating it as a host)

• ps -eL -o cpuid -o tid -o pid -o comm -o stat -o command | egrep -i 'PID|ptsm‘

• taskset –p <mask> <tid>

• ssh tpc-e3-12-019 ...