363 lines
24 KiB
TeX
363 lines
24 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% writeLaTeX Example: A quick guide to LaTeX
|
||
%
|
||
% Source: Dave Richeson (divisbyzero.com), Dickinson College
|
||
%
|
||
% A one-size-fits-all LaTeX cheat sheet. Kept to two pages, so it
|
||
% can be printed (double-sided) on one piece of paper
|
||
%
|
||
% Feel free to distribute this example, but please keep the referral
|
||
% to divisbyzero.com
|
||
%
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% How to use writeLaTeX:
|
||
%
|
||
% You edit the source code here on the left, and the preview on the
|
||
% right shows you the result within a few seconds.
|
||
%
|
||
% Bookmark this page and share the URL with your co-authors. They can
|
||
% edit at the same time!
|
||
%
|
||
% You can upload figures, bibliographies, custom classes and
|
||
% styles using the files menu.
|
||
%
|
||
% If you're new to LaTeX, the wikibook is a great place to start:
|
||
% http://en.wikibooks.org/wiki/LaTeX
|
||
%
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\documentclass[10pt,landscape]{article}
|
||
\usepackage{amssymb,amsmath,amsthm,amsfonts}
|
||
\usepackage{multicol,multirow}
|
||
\usepackage{calc}
|
||
\usepackage{ifthen}
|
||
\usepackage{graphicx}
|
||
%\usepackage[fontsize=6pt]{fontsize}
|
||
|
||
\usepackage{helvet}
|
||
\renewcommand{\familydefault}{\sfdefault}
|
||
\usepackage[landscape]{geometry}
|
||
|
||
\geometry{a4paper, landscape, margin=0.5in}
|
||
\usepackage[colorlinks=true,citecolor=blue,linkcolor=blue]{hyperref}
|
||
\usepackage[
|
||
protrusion=true,
|
||
activate={true,nocompatibility},
|
||
final,
|
||
tracking=true,
|
||
kerning=true,
|
||
spacing=true,
|
||
factor=1100]{microtype}
|
||
\SetTracking{encoding={*}, shape=sc}{40}
|
||
%%Packages added by Sebastian Lenzlinger:
|
||
\usepackage{enumerate} %% Used to change the style of enumerations (see below).
|
||
|
||
\newtheorem{definition}{Definition}
|
||
\newtheorem{theorem}{Theorem}
|
||
\newtheorem{axiom}{Axiom}
|
||
\newtheorem{lem}{Lemma}
|
||
\newtheorem{corr}{Corollary}
|
||
|
||
\usepackage{tikz} %% Pagacke to create graphics (graphs, automata, etc.)
|
||
\usetikzlibrary{automata} %% Tikz library to draw automata
|
||
\usetikzlibrary{arrows} %% Tikz library for nicer arrow heads
|
||
%%End
|
||
\microtypecontext{spacing=nonfrench}
|
||
|
||
\ifthenelse{\lengthtest { \paperwidth = 11in}}
|
||
{ \geometry{top=.5in,left=.5in,right=.5in,bottom=.5in} }
|
||
{\ifthenelse{ \lengthtest{ \paperwidth = 297mm}}
|
||
{\geometry{top=0.5cm,left=0.5cm,right=0.5cm,bottom=0.5cm} }
|
||
{\geometry{top=1cm,left=1cm,right=1cm,bottom=1cm} }
|
||
}
|
||
\pagestyle{empty}
|
||
\makeatletter
|
||
\renewcommand{\section}{\@startsection{section}{1}{0mm}%
|
||
{0.1mm}%
|
||
{0.0mm}%x
|
||
{\normalfont\normalsize\bfseries}}
|
||
\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}%
|
||
{0.01mm}%
|
||
{0.0001mm}%
|
||
{\normalfont\small\bfseries}}
|
||
\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}%
|
||
{-1ex plus -.5ex minus -.2ex}%
|
||
{1ex plus .2ex}%
|
||
{\normalfont\small\bfseries}}
|
||
\makeatother
|
||
\setcounter{secnumdepth}{0}
|
||
\setlength{\parindent}{0pt}
|
||
\setlength{\parskip}{0pt plus 0.5ex}
|
||
% -----------------------------------------------------------------------
|
||
|
||
\title{Operating Systems FS23}
|
||
|
||
\begin{document}
|
||
\tiny
|
||
\raggedright
|
||
\footnotesize
|
||
|
||
\begin{multicols*}{3}
|
||
\setlength{\premulticols}{1pt}
|
||
\setlength{\postmulticols}{1pt}
|
||
\setlength{\multicolsep}{1pt}
|
||
\setlength{\columnsep}{1pt}
|
||
\section{Intro}
|
||
\textbf{Batch Systems:} Multiprogramming, job queue, job scheduling, no interactivity, Job Switch possibile (e.g. wait on I/O). Reduce setup time by batching.
|
||
\textbf{Time-sharing:} multitasking, frequent change of currently running job, cpu scheduler, interactivity, 'concurrent processes', virtual memory.\\ \textbf{Summary}
|
||
• OS efficiently manage various resources (processes, memory, I/O, files, security) but
|
||
also ‘extend’ machines with user abstractions: processes, address spaces, files.
|
||
• OS can only execute programs available in the main memory (the only large storage
|
||
area that the processor can access directly).
|
||
• Storage hierarchy ranges from small and fast but expensive (registers, caches) to larger
|
||
and slower, but less expensive (main memory- volatile), to even larger and much
|
||
slower, and much less expensive (disk - nonvolatile, magnetic tapes – nonvolatile).
|
||
• Caching brings programs and data closer to the CPU for execution.
|
||
• Switch to kernel mode involves: I/O control, timer management, and interrupt management.
|
||
• Ontogeny Recapitulates Phylogeny: changes in technology may bring obsolete concepts back.
|
||
|
||
\section{OS Structures}
|
||
\textbf{Syscalls } •\emph{Implementation}: Typically, a number associated with each system call
|
||
– System call interface maintains a table indexed according to these
|
||
numbers
|
||
The system call interface invokes the intended system call in OS kernel
|
||
and returns status of the system call and any return values
|
||
The caller need know nothing about how the system call is implemented
|
||
– Just needs to ‘obey’ API and understand what OS will do as a result call
|
||
– Most details of OS interface hidden from programmer by API
|
||
– Managed by runtime support library (set of functions built into libraries
|
||
included with compiler). •\emph{Parameter Passing}: Often, more information is required than simply the identity of the desired
|
||
system call
|
||
– Exact type and amount of information vary according to OS and call
|
||
General methods used to pass parameters to the OS
|
||
1. Simplest: pass the parameters in registers
|
||
– In some cases, may have more system call parameters than registers
|
||
2. Parameters stored in a block, or table, in memory, and address of
|
||
block passed as a parameter in a register
|
||
– Approach taken by Linux and Solaris
|
||
– Does not limit the number or length of parameters being passed
|
||
3. Parameters placed, or pushed, onto the stack by the program and
|
||
popped off the stack by the operating system
|
||
– Does not limit the number or length of parameters being passed.
|
||
|
||
\textbf{Monolithic Systems} • Advantages
|
||
- Interaction between OS modules is easy and efficient
|
||
- Very little overhead in system call interface
|
||
- Communication within the kernel is fast
|
||
• Disadvantages
|
||
- Difficult to oversee and to follow through
|
||
- Difficult to maintain, perform local changes
|
||
- Stability (single-point of failure)
|
||
- Failure in a single module can threaten the entire system
|
||
- Complexity increases with kernel scale
|
||
|
||
\textbf{Summary: }
|
||
•OS: environment to execute programs; provides services to users and programs.
|
||
•User-OS interfaces: (1) command interpreters, (2) GUI, and (3) touch-screen.
|
||
•System calls at the heart of OS: interface to the services offered by OS
|
||
•Process control (creation and termination), file management (reading and writing),
|
||
device management, information management, communication, protection
|
||
•System programs: provide utilities to users
|
||
•A linker combines several relocatable object modules into a single binary
|
||
executable file. A loader loads the executable file into memory, where it
|
||
becomes eligible to run on an available CPU.
|
||
•Applications are OS-specific due to differences in binary formats, instruction
|
||
sets, system calls
|
||
•OS structures are monolithic, layered, microkernel, modular, and hybrid
|
||
|
||
\section{Processes}PCB is an internal struct for process management. Contains all relevant information of the process(Process state, PID, cpu registers etc. This is not the same as the process memory layout. Executable code is not part of the PCB. Multiple PC $\xrightarrow{}multithreading$ .
|
||
|
||
\section{Scheduling}
|
||
\emph{Short-term} (CPU) Schedules from ready queue and allocates CPU.
|
||
\emph{Mid-term} swapping: decrease \# processes in memory if necessary.
|
||
\emph{Long-term} Selects process to bring into ready queue. Controlls degree of multi-programming.
|
||
\textbf{Summary: }CPU scheduling: selecting a waiting process from the ready queue and
|
||
allocating the CPU to it (by the dispatcher).
|
||
• Scheduling algorithms: either preemptive (where the CPU can be taken
|
||
away from a process) or nonpreemptive (where a process must voluntarily
|
||
relinquish control of the CPU).
|
||
• Almost all modern operating systems are preemptive.
|
||
• Scheduling algorithms evaluation criteria: (1) CPU utilization, (2) throughput,
|
||
(3) turnaround time, (4) waiting time, (5) response time.
|
||
• First-come, first-served (FCFS) scheduling: simplest scheduling algorithm, can
|
||
cause short processes to wait for very long processes.
|
||
• Shortest-job-first (SJF) scheduling is provably optimal, providing shortest
|
||
average waiting time. Implementation is difficult because predicting the length
|
||
of the next CPU burst is difficult.
|
||
• Round-robin (RR) scheduling allocates the CPU to each process for a time
|
||
quantum (q). If process does not relinquish the CPU before its q expires,
|
||
process is preempted, and another process is scheduled to run for a q.
|
||
• Priority scheduling (Prio) assigns each process a priority, and CPU is allocated
|
||
to the process with the highest priority. Same priority processes can be
|
||
scheduled in FCFS order or using RR scheduling.
|
||
• Multilevel queue (MLQ) scheduling partitions processes into several separate
|
||
queues arranged by priority, and the scheduler executes processes in the
|
||
highest-priority queue. Different scheduling algorithms may be used in each
|
||
queue.
|
||
• Multilevel feedback queues (MLFQ) are similar to multilevel queues, except
|
||
that a process may migrate between different queues.
|
||
• Multicore processors place one/more CPUs on same physical chip, each CPU
|
||
may have more than one hardware thread. OS sees each hardware thread as
|
||
a logical CPU.
|
||
• Load balancing on multicore systems equalizes loads between CPU cores;
|
||
thread migration between cores to balance loads may invalidate cache
|
||
contents and increase memory access times.
|
||
\textbf{Shared memory} is under the control of user space, not OS. User process has to synchronize when accessing shared memory.
|
||
|
||
\textbf{Prod. Consumer Problem} Bounded Buffer requires sync.
|
||
\textbf{Message Passing} Com. Link implmented 1. Physcal: Shared Mem, HW Bus, Network. 2. Logical: Direct (send,recv via ProcessID)/Indirect(via Mailbox(aka Ports)), Sync/Async, Auto/Explicit. • \emph{Syncing} Blocking or Non-Blocking. Rendevouz: both send and recv blocking: correctness guaranteed, lower performance.
|
||
\section{Syncro}
|
||
• Race condition: processes have concurrent access to shared data
|
||
and the final result depends on the particular order in which concurrent
|
||
accesses occur. Can result in corrupted values of shared data.
|
||
• Critical section: section of code where shared data may be
|
||
manipulated and a possible race condition may occur. The criticalsection problem (CSP) is to design a protocol whereby processes
|
||
can synchronize their activity to cooperatively share data.
|
||
• Solutions to CSP must fulfil: (1) mutual exclusion, (2) progress, and (3)
|
||
bounded waiting.
|
||
• Software solutions to the critical-section problem, such as Peterson's
|
||
solution, do not work well on modern computer architectures.
|
||
• A mutex lock provides mutual exclusion by requiring that a process acquire
|
||
a lock before entering a critical section and release the lock on exiting the
|
||
critical section.
|
||
• Semaphores, like mutex locks, can be used to provide mutual exclusion.
|
||
However, whereas a mutex lock has a binary value that indicates if the
|
||
lock is available or not, a semaphore has an integer value and can
|
||
therefore be used to solve a variety of other synchronization problems.
|
||
• A monitor is an abstract data type that provides a high-level form of
|
||
process synchronization. A monitor uses condition variables that allow
|
||
processes to wait for certain conditions to become true and to signal one
|
||
another when conditions have been set to true.
|
||
• Solutions to the critical-section problem may suffer from deadlocks.
|
||
\textbf{Deadlocks Characterization: } A deadlock can arise if all these four (non-independent) conditions hold
|
||
simultaneously:
|
||
\textbf{D1}. Mutual exclusion: only one process at a time can use a resource.
|
||
\textbf{D2}. Hold and wait: a process holding at least one resource is waiting to
|
||
acquire additional resources held by other processes.
|
||
\textbf{D3}. No preemption: a resource can be released only voluntarily by the
|
||
process holding it, after that process has completed its task.
|
||
\textbf{D4}. Circular wait: there exists a set {P0, P1, …, Pn} of waiting processes
|
||
such that P0 is waiting for a resource that is held by P1, P1 is waiting for a
|
||
resource that is held by P2, …, Pn–1 is waiting for a resource that is held
|
||
by Pn, and Pn is waiting for a resource that is held by P0. •\emph{Deadlock Prevention: } Avoid deadlock by having a strict lock hierarchy, i.e. addressing D.4 (only practical option).
|
||
\section{Main Memory}
|
||
\textbf{Address Binding}: Important: addresses represented in different ways at different stages of
|
||
a program’s life
|
||
– Source code addresses usually symbolic (not physical). Compile Time: If mem loc known, abs. code location generatable; recompile of loc. on changes.
|
||
– Compiled code addresses bind to relocatable memory addresses.
|
||
– i.e., “14 bytes from beginning of this memory module”
|
||
– Linker or loader will bind relocatable addresses to absolute addresses, if not know at compile time.
|
||
– Each binding maps one address space to another:
|
||
code addresses to relocatable addresses to absolute addresses
|
||
- Execute time: binding here if proc relocatable during execution (need hw support). Most OSs bind at exec time.
|
||
\textbf{MMU:} HW device maps virt to phys add \emph{during execution}. logicl add. plus reloc. reg. = relocable mem add. \textbf{Exec-time addr binding: }log. addr. bound during exec. by MMU.
|
||
\textbf{Dynamic Loading }($\not =$ d.linking) routine loaded only when called.
|
||
\textbf{Two Paritions:} User proc (in low physical mem) plus resident OS(in high physical mem with interupt vec). \emph{Contiguous alloc:} each proc in single section of memm.
|
||
\textbf{Mem protect:} Reloc plus limit reg used in context switch to protect user proc form each other. MMU \emph{dynamically} maps log. to phys. addr.
|
||
\textbf{Multiple Part:} Deg. of multiprog. limmited by no. of part. in mem. for procs. \emph{Variable part. size.} for efficiency.
|
||
\emph{First-fit:} allocate first hole.equiv to best-fit for storage, but faster. \emph{Best-fit:} smallest hole. large enough. must search entire list, unless ordered by size. $\Rightarrow$ get smallest leftover area.
|
||
\textbf{External fra.} many small, non-contiguous holes. Results in unusable memory.\emph{SOl:} Compaction: shuffle mem content to have all free mem in 1 large block. Only possible if dyn. addr. reloc. aka done at exec time. also: non-contiguous alloc see paging. \textbf{Internal frag:} alloc mem block may be larger than requested $\Rightarrow$ not whole block used.
|
||
\textbf{Paging:} alloc proc mem whenever and wherever available. procs. phys. addr. may be non-contiguous. Physical addr. div into fixed size blocks aka \emph{frames.}. Log. mem. div. into \emph{pages.}
|
||
Use \emph{page table} to map N pages to N frames. Starage also split into same size blocks. •Addr trans scheme: trans page number p to frame number f, use same offset d. frame ID times pagesize plus offset $=$ phys.mem. addr. Like using table of base/relocation regs, per mem frame. $\Rightarrow$ NO external fragmentation. IMPORTANT: Page table is \emph{per proc}.
|
||
\textbf{Paging implementatin:} HW w.o. TLB: every data/instr access need two mem access: page table then frame. With TLB: HW cache aka TLB with key,val pars. if TLB miss get from page table in mem.
|
||
\textbf{Protection:} bit indicating RO or RW(can add more e.g. for exec). Valid-Invalid bit, additional bit per entry in PT set by OS. indicates if page in LAS of proc. Violation results in trap to kernel.
|
||
\textbf{Demand Pageing Page Fault Handling:} 1. Ref. LA in PT invalid bit. 2. Trap to OS. 3. Page in storge. 4. bring in missing page to free frame. 5.reset PT 6. restart instruction.
|
||
\textbf{Page Replacement Algorithms: } FIFO, Least recently used, Optimal Algo (OTP) as reference.
|
||
\textbf{Frame Alloc Algo:} 1.Fixed: 1.1Equal, m frames n proces so m/n frames/proc. 1.2Proportional,then dep on size of programm. 2. Prority based: Proportional scheme plus prority instead of size (or size and prio mixed). \textbf{Global Repl:} Pro: greater troughput.more commonly used) Con: proc exec time can greatly vary. \textbf{Local Repl:} Pro: more consistent per proc perf. Con: unerutilized memory.
|
||
|
||
\textbf{Thrashing} Proc needs frames, high Page fault, get desired page, replace existing frame, quickly need replaced frame back, repeat. CPU seems unused $\Rightarrow$ OS gives CPU more work, thrashing repeats even more.
|
||
\textbf{Locality:} Set of pages activly used together by proc. Model:Proc fault for locality until all pages of local in mem. not fault again until locality changes. Localities may overlap. A \textbf{working set} is based on locality and is defined as the set of pages currently in
|
||
use by a process
|
||
|
||
\section{FileSys}
|
||
• File: an abstract data type defined and implemented by OS. It is a sequence of logical records. A logical record may be a byte, a line (of fixed or variable length), or a more complex data item.
|
||
• File operations: create, open, write, read, reposition, delete, truncate • File access methods: sequential and direct • Directories: Within a file system, it is useful to create directories to allow files to be organized.
|
||
• Tree-structured directory allows a user to create subdirectories to
|
||
organize files.
|
||
• Acyclic-graph directory: enable users to share subdirectories and files but complicate searching and deletion.
|
||
• A general graph: allows complete flexibility in the sharing of files and directories but sometimes requires garbage collection to recover
|
||
unused disk space.
|
||
• Most file systems reside on secondary storage, which is designed to hold a large amount of data permanently
|
||
• The most common secondary-storage medium is the disk, but the use of NVM devices is increasing
|
||
• File systems are mounted onto a logical file system architecture to make them available for use
|
||
• File systems are often implemented in a layered or modular structure • Files within a file system can be allocated space on the storage device in three ways: through contiguous, linked, or indexed allocation
|
||
• Contiguous allocation can suffer from external fragmentation. • Direct access is very inefficient with linked allocation.
|
||
• Indexed allocation may require substantial overhead for its index block.
|
||
• Free-space allocation methods also influence the efficiency of diskspace use, the performance of the file system, and the reliability of secondary storage.
|
||
• Free-space allocation methods include bit vectors and linked lists.
|
||
• A general-purpose computer system can have multiple storage devices, and those devices can be sliced up into partitions, which hold volumes, which in turn hold file systems
|
||
• File systems must also be mounted before they are used • A mount point is a location within the directory structure where the file system will be attached
|
||
• A boot loader is a set of blocks that contain enough code to know how to load the kernel from the file system
|
||
• The root partition selected by the boot loader must be mounted at boot
|
||
time
|
||
\section{Security}
|
||
• A general-purpose computer system can have multiple storage devices, and those devices can be sliced up into partitions, which hold volumes, which in turn hold file systems
|
||
• File systems must also be mounted before they are used • A mount point is a location within the directory structure where the file system will be attached
|
||
• A boot loader is a set of blocks that contain enough code to know how to load the kernel from the file system
|
||
• The root partition selected by the boot loader must be mounted at boot
|
||
time
|
||
• System protection features are guided by the principle of need-toknow and implement mechanisms to enforce the principle of least privilege.
|
||
• Computer systems contain objects that must be protected from misuse.
|
||
• Objects may be hardware (such as memory, CPU time, and I/O devices) or software (such as files, programs, and semaphores).
|
||
• An access right is permission to perform an operation on an object. • A domain is a set of access rights. • Processes execute in domains and may use any of the access rights
|
||
in the domain to access and manipulate objects.
|
||
• The access matrix is a general model of protection that provides a mechanism for protection without imposing a particular protection policy on the system or its users
|
||
• The access matrix is sparse. It is normally implemented as access
|
||
lists associated with each object
|
||
\section{Virtualization:}
|
||
\textbf{Trap-and-emulate:}
|
||
• A virtual machine guest can execute only in user mode
|
||
• The kernel, of course, runs in kernel mode, and it is not safe to allow userlevel code to run in kernel mode
|
||
• We must have a virtual user mode and a virtual kernel mode, both of which run in physical user mode.
|
||
• A transfer from virtual user mode to virtual kernel mode in the virtual machine happens when privileged
|
||
instructions are executed
|
||
|
||
\textbf{Binary Translation:}
|
||
• Some CPUs do not have a clean separation of privileged and nonprivileged instructions
|
||
• Binary Translation is a technique that makes VMM inspect all instructions initiated by the guest OS.
|
||
• Instructions that would behave differently in real kernel mode translated into a set of new
|
||
instructions
|
||
\textbf{Hypervisors:}
|
||
• Type 0 Hypervisor • have existed for many years under many names, including “partitions” and “domains.”
|
||
• The VMM itself is encoded in the firmware and loaded at boot time
|
||
• VMM loads the guest images to run in each partition.
|
||
• The feature set of a type 0 hypervisor tends to be smaller than those of the other types because it is
|
||
implemented in hardware
|
||
• Type 1 hypervisor (bare metal) • commonly found in company data centers • special-purpose operating system that runs natively on the hardware
|
||
• Type 2 hypervisor (hosted) • simply another process run and managed by the host OS • the host host OS does not know that virtualization is happening
|
||
• there is very little operating-system involvement in type 2 hypervisor
|
||
• Both type 1 and type 2 hypervisors work with unmodified guest operating systems and they have to jump through hoops to get good performance (recall trap-thenemulate approach)
|
||
• Paravirtualization takes another approach. It avoid causing traps by modifying the source code of the
|
||
guest operating system
|
||
\section{OS \& Performance}
|
||
• The OS decides mapping of Processes/Threads in time and space
|
||
• Preemptive scheduling to enable fairness among all threads
|
||
• Too long Time Quantum => less responsiveness of the applications
|
||
• Too short Time Quantum => frequent context switches
|
||
• The OS decides mapping of Processes/Threads in time and space
|
||
• Migrating the thread to a different CPU core.
|
||
• Load Balancing aims to evenly distribute the workload across available
|
||
CPU cores to maximize overall system performance
|
||
• Cache Affinity refers to the preference for a thread to execute on the same
|
||
CPU core where its associated cache data resides
|
||
• OS memory management ensures that applications receive sufficient
|
||
and contiguous memory blocks, minimizing fragmentation, and
|
||
optimizing memory usage
|
||
• Memory Paging
|
||
• Page Size
|
||
• Too large: leads to internal fragmentation
|
||
• Too small: leads to external fragmentation, where free memory is divided
|
||
into small, non-contiguous blocks, making it challenging to allocate larger
|
||
memory chunk
|
||
• Efficient and optimized file systems can improve file access times and
|
||
overall I/O performance
|
||
• Well-designed I/O scheduling algorithms can minimize seek times,
|
||
reduce I/O bottlenecks, and enhance application responsiveness
|
||
• Buffering and caching mechanisms reduce physical disk accesses,
|
||
improving I/O performance by providing faster access times
|
||
• Asynchronous I/O allows for concurrent execution of I/O operations,
|
||
minimizing I/O-related delays and optimizing resource utilization
|
||
|
||
%\includegraphics[width=\linewidth]{images/memtable.png}O
|
||
\end{multicols*}
|
||
\end{document} |