OS Experiential Learning Research Assignment

Group-7:
Riya Chaudhary, 17070122056

Chrome OS
Introduction
Chrome OS is a Linux kernel-based operating system designed by Google. It is derived from the free
software Chromium OS and uses the Google Chrome web browser as its principal user interface. As a
result, Chrome OS primarily supports web applications. Written in C, C++, it was conceived as an
operating system in which both applications and user data reside in cloud.
Google Chrome Operating System uses the 3.4.6 Linux kernel to provide a virtual machine interface
designed to abstract the hardware layer to maximize productivity. The kernel is an upgrade from the
original 2.6 Linux kernel that Google Chrome Operating System was originally using and provides
services such as the Process Scheduler, Memory Manager, Virtual File System, Network Interface,
and Inter-Process Communication. The first Chrome OS laptop, known as a Chromebook, arrived in
May 2011. Initial Chromebook shipments from Samsung and Acer occurred in July 2011. It is synced,
backed up and updated automatically. The older version called Chromium OS had drawback which
have been addressed in chrome OS.

Chromium OS Chrome OS
Chrome Operating system Architecture

The Hardware:
Laptops running Chrome OS are known collectively as "Chromebooks". The first was the CR-48,
a reference hardware design that Google gave to testers and reviewers beginning in December 2010.
In May 2012, a desktop design marketed as a "Chromebox" was released by Samsung. In early
2014, LG Electronics introduced the first device belonging to the new all-in-one form factor called
"Chromebase". Chromebase devices are essentially Chromebox hardware inside a monitor with
built-in camera, microphone and speakers.
The Chromebit is an HDMI dongle running Chrome OS. When placed in an HDMI slot on a television
set or computer monitor, the device turns that display into a personal computer. The device was
announced in March 2015 and shipped that November.
Chrome OS supports dual-monitor setups, on devices with a video-out port.
Architecture
Chrome OS is built on top of the Linux kernel. Originally based on Ubuntu, its base was changed
to Gentoo Linux. In preliminary design documents for the Chromium OS open source project, Google
described a three-tier architecture: firmware, browser and window manager, and system-level
software and userland services.

 The firmware contributes to fast boot time by not probing for hardware, such as floppy disk
drives, that are no longer common on computers, especially netbooks. The firmware also
contributes to security by verifying each step in the boot process and incorporating system
recovery.
 System-level software includes the Linux kernel that has been patched to improve boot
performance. Userland software has been trimmed to essentials, with management by Upstart,
which can launch services in parallel, re-spawn crashed jobs, and defer services in the interest of
faster booting.
 The window manager handles user interaction with multiple client windows much like other X
window managers.
Process Management
The operating system tracks processes through a five-digit ID number known as the pid or
the process ID. Each process in the system has a unique pid.
When you start a process (run a command), there are two ways it can run

 Foreground Processes: By default, every process that you start runs in the foreground. It
gets its input from the keyboard and sends its output to the screen.
 Background Processes: A background process runs without being connected to the keyboard.
If the background process requires any keyboard input, it waits. The advantage of running a
process in the background is that the user can run other commands; they do not have to wait
until it completes to start another

Crosh, short for Chrome shell, includes the top command from Linux, which gives you a display of all
the low-level processes that might also be using resources. It is an interactive diagnostic tool that
updates frequently and shows information about physical and virtual memory, CPU usage, load
averages, and your busy processes.

The Process Scheduler

The Process Scheduler’s purpose it to control process access to the CPU. Operating systems use a
variety of types of schedulers to do so. The Google Chrome Operating System uses the Completely
Fair Scheduler. This scheduler is designed to balance or maintain fairness, by splitting up processor
time to tasks. To do this the scheduler uses a virtual runtime to keep track of the length of time
provided to task at hand. This way the task that has been permitted the least amount of time to the
processor, becomes the task that needs the processor the most. The Completely Fair Scheduler uses
a red black tree to sort by time. The red black tree is ideal for the scheduler, for red black trees only
allow the furthest node to be one level lower. In addition, red black trees big O time is O(log n)
allowing for fast operations. The Completely Fair Scheduler also allows for group scheduling. Group
scheduling ensures that in situations where tasks spawn other tasks, each single task is ensured their
own virtual runtime rather than treating tasks uniformly.

Parent and Child Processes

Each process has two ID numbers assigned to it: The Process ID (pid) and the Parent process ID (ppid).
Each user process in the system has a parent process.

Most of the commands that you run have the shell as their parent. Check the ps -f example where
this command listed both the process ID and the parent process ID.
Daemon Processes
Daemons are system-related background processes that often run with the permissions of root and
services requests from other processes.

A daemon has no controlling terminal. It cannot open /dev/tty. If you do a "ps -ef" and look at
the tty field, all daemons will have a ? for the tty.

To be precise, a daemon is a process that runs in the background, usually waiting for something to
happen that it is capable of working with. For example, a printer daemon waiting for print commands.

Zombie and Orphan Processes

Normally, when a child process is killed, the parent process is updated via a SIGCHLD signal. Then the
parent can do some other task or restart a new child as needed. However, sometimes the parent
process is killed before its child is killed. In this case, the "parent of all processes," the init process,
becomes the new PPID (parent process ID). In some cases, these processes are called orphan
processes.

When a process is killed, a ps listing may still show the process with a Z state. This is a zombie or
defunct process. The process is dead and not being used. These processes are different from the
orphan processes. They have completed execution but still find an entry in the process table.

Stopping Processes
The first step in killing the unresponsive process is locating it. Ending a process can be done in several
different ways. Often, from a console-based command, sending a CTRL + C keystroke (the default
interrupt character) will exit the command. This works when the process is running in the foreground
mode.

If a process is running in the background, you should get its Job ID using the ps command. Background
and suspended processes are usually manipulated via job number (job ID). This number is different
from the process ID and is used because it is shorter. In addition, a job can consist of multiple
processes running in a series or at the same time, in parallel. Using the job ID is easier than tracking
individual processes.

After that, the kill command is used to kill the process as follows

Memory Management
● Segmentation
● Paging
● zones
Memory Allocation/ Deallocation

● Buddy Algorithm : It maintains different free lists with different sizes in each zone Ex: 4,8,16,32,64
group of free lists. i.e free list 4 contains(4 pages)

● Slab Algorithm : It creates a cache for each frequently used kernel data structures. Ex: inode,
task_struct, mm_struct etc. Cache is a collection of slabs Slab size may be one or two pages. Slab
contains a group of objects of similar type.
Page Cache : logically divides physical memory into two types
1. One is Page cache
2. Another one is anonymous memory
It holds the contents of files etc. It provides sharing among different process. It uses copy-on-write
mechanism.

Page frame Reclaiming Algorithm : If low memory, situation arises then kernel calls reclaiming
algorithm. It uses kswapd deamon for reclaiming frames. Each process maintains two lists
1. Active list: Holds frequently used pages ●
2. Inactive list: Holds less frequently used pages.
Kswapd traverses each process and reclaims pages until free memory size > some threshold.

The Memory Manager - The Google Chrome Operating System’s, purpose is to control
process access to the hardware’s memory components. The Memory Manager is able to do
so by using a hardware memory management system which supports mapping to occur from
the process memory identifying code to the systems memory. This allows processes to all
access main memory at the same time.
Most Chromebooks come with 16 GB’s of storage, the rest of the user’s data is stored
through cloud storage. Cloud storage is a network of online storage where data can be
saved using virtual storage in our case housed by Google. Data centres act as warehouses
where cloud data is stored. For cloud storage to work all that is needed is one server that
has access to the web. When a client decides to store data, a copy of the data instead of the
data itself, is sent over the connection the server’s data centre where it will be stored until
the client sends the signal to retrieve the data.

RAM classification

I/o Management
Chrome uses request structures to pass the I/O requests to the devices. All the block devices
maintain a list of request structures. When a buffer is to be read or written, the kernel
calls ll_rw_block() routine and passes it an array of pointers to buffer heads. ll_rw_block() routine in
turn calls make_request() routine for each buffer. make_request() first tries to cluster the buffer
with the existing buffers in any of the request structures present in the device queue.
A request structure consists of a list of buffers which are adjacent on the disk. This clustering is
performed only for the drivers compiled in the kernel and not for loadable modules. If clustering is
possible, no new request structure is created, otherwise a new request is taken from the global pool
of structures and initialized with the buffer and is passed to the add_request() routine. This routine
applies the elevator algorithm using insertion sort based on the minor number of the device and the
block number of buffer. If the device queue is empty, the kernel calls the strategy routine i.e.
the request_fn() of the driver; otherwise, it is the responsibility of the driver to reinvoke it from the
interrupt context. Another requirement for request_fn() is that it cannot block as it needs to be
called from the interrupt context.
To allow the accumulation of requests in the device queue, a plug is used. When the request comes
in and the device queue is empty, the plug is put at the head of the device queue, and a task
comprising of the unplug function is registered in the disk task queue. Thus the requests keep on
accumulating for some time and then the task queue executes the unplug routine which removes
the plug and calls the request_fn() to service the requests.

Synchronization
Since chrome OS is based on Linux, it uses the same process synchronization as in Linux. This
involves providing a time slice for each process so that they get the required time for execution. The
process can be created using the fork() command. The creating process is called the parent process
and the created process is the child process. A child process can have only one parent but a parent
process may have many children. Both the parent and child processes have the same memory
image, open files and environment strings. However, they have distinct address spaces.

System processes tend to fall into two types: interactive and non-interactive. Interactive processes
are heavily dependent upon I/O and, as a result, do not usually use their entire time slice and,
instead, yield the CPU to another process. Non-interactive processes are heavily dependent on the
CPU and typically use most, if not all, of their time slice. The scheduler has to balance the
requirements of these two types of processes and attempt to ensure every process gets enough
time to accomplish its task without detrimentally affecting the execution of other processes.

The scheduler finds the highest priority process to run via sched_find_first_bit() and then sets
up queue to point to the list held in the priority array at the specified location. next is initialized to
the first process in queue. If the process to be activated is dependent on a sibling that is sleeping, we
choose a new process to be activated and jump to switch_tasks to continue the scheduling function.

Suppose that we have Process A that spawned Process B to read from a device and that Process A
was waiting for Process B to finish before continuing. If the scheduler chooses Process A for
activation, this section of code, dependent_sleeper(), determines that Process A is waiting on
Process B and chooses an entirely new process to activate. If the process’ activated attribute is
greater than 0, and the next process is not a real-time task, we remove it from queue, recalculate its
priority, and enqueue it again. We set the process’ activated attribute to 0, and then run with it.

Context Switch
Called from schedule() in /kernel/sched.c, context_switch() does the machine-specific work of
switching the memory environment and the processor state. In the abstract, context_switch swaps
the current task with the next task. The function context_switch() begins executing the next task and
returns a pointer to the task structure of the task that was running before the call.