Memory Management of Linux

 https://www.youtube.com/watch?v=7aONIVSXiJ8

Direct Memory Access (DMA)

Reference:

If IO device (such as disk controller) needs data to be written or read from the memory, it used to to through the CPU like below.

In the above image, if IO can talk to/access memory directly, the number of cycles will reduce drastically. To achieve this direct memory access by an IO device, a special called DMA controller is needed.

Now, there are 4 components involved in DMA theory. Picture below.

YOUTUBE LINK: https://www.youtube.com/watch?v=Xkpu8BXi3aI

Here is how it works:
1. 

Socket Programming - Part 1

Reference: http://www.tenouk.com/cnlinuxsockettutorials.html

Port Numbers

• 16 bit integers
• So a maximum port numbers are 2^16 = 65536 (0 to 65535)
• Unique with a machine/IP address
• Each service/application/daemon will have their own port number 
• Required to make a connection (along with its host IP address)

Server & Client Port Numbers

• Connection is defined by: (Server IP and Port number) + (Client IP and port number)
• Server Port numbers are low numbers in the range 1 - 1023 (called as WELL KNOWN PORT NUMBER)
• Accessible only by Administrators (roots, in linux)
• Used for authentication
• A server running on a well-known port lets the OS know what port it wants to listen on
• Normally, client port numbers are higher number starting at 1024
• Client normally simples lets the OS picks a new port that is not already in use.

Locks in Multi-processing/multi-thread programming

DeadLock:
A deadlock is a situation wherein two or more competing actions are each waiting for the other to finish, and thus neither ever does.


LiveLock:

A livelock is similar to a deadlock, except that the states of the processes involved in the livelock constantly change with regard to one another, none progressing. Livelock is a special case of resource starvation; the general definition only states that a specific process is not progressing.

A real-world example of livelock occurs when two people meet in a narrow corridor, and each tries to be polite by moving aside to let the other pass, but they end up swaying from side to side without making any progress because they both repeatedly move the same way at the same time.

Livelock is a risk with some algorithms that detect and recover from deadlock. If more than one process takes action, the deadlock detection algorithm can repeatedly trigger. This can be avoided by ensuring that only one process (chosen randomly or by priority) takes action.

Socket Programming - ASYNCHRONOUS

What is Asynchronous Socket Programming?

• "Event-driven" programming or "select()" based multiplexing
• A concept of "handling" multiple connections in "single thread/process"

When do we need this?

• Assume you have to write a server that will be "hit" by "n" number of clients with some requests
• You would prefer any of the follow

• synchronous: you handle one request at a time, each in turn.
  pros: simple
  cons: any one request can hold up all the other requests
• fork: you start a new process to handle each request.
  pros: easy
  cons: does not scale well, hundreds of connections means hundreds of processes.
  fork() is the Unix programmer's hammer. Because it's available, every problem looks like a nail. It's usually overkill
• threads: start a new thread to handle each request.
  pros: easy, and kinder to the kernel than using fork, since threads usually have much less overhead
  cons: your machine may not have threads, and threaded programming can get very complicated very fast, with worries about controlling access to shared resources.

• The best solution would be "select" system call.

How "select" works?

• The normal heirarchy of socket programming calls in the server side would be "socket()->bind()->listen()->accept()".
• If you notice, here "accept" is the blocking call. In order to avoid this blocking stuff, we use "select" which will "run" through all the connected sockets to check if there are any requests pending for "reading, writing or error conditions".
• If any requests pending, "select" will return the number of requests pending to be processed.
• Hence the heirarchy would be "socket()-> bind()->listen()->select()->accept()"
• But here the disadvantage is that, we need to iterate through all the "connections" (descriptors) connected to check "Are you the one with pending requests?" questions.

Copy-On-Write

Copy-On-Write (COW)

1. optimization strategy used in computer systems
2. Idea is that if multiple callers ask for resources, they can all be given pointers to the same resource. Now, all "callers" (processes) will be in assumption that "I m holding this X resource; and I can do whatever I want". But, when this "caller" tries to modify its so - called "My resource X", a true private copy is created actually, to prevent the changes becoming visible to other "callers".
3. Hence, the primary advandage is that if a caller never makes any modifications, *NO PRIVATE COPY IS CREATED*.

In Virtual Memory:

• COW finds its main-use in virtual memory OS; when a process creates a copy of itself (fork), the pages in memory that might be modified by either the process or its copy, are marked "Copy-On-Write".
• When one process modifies the memory, the OS kernel intercepts the operation and copies the memory so that changes in one process's memory are not visible to other

COW and MMU

• COW can be implemented by telling MMU that certain pages in the process's address space are read only.
• When data is written to these pages, MMU raises an exception which is handled by kernel, which allocates new space in physical memory and makes the page being written to correspond to that new location in physical memory

Memory mapped and IO mapped devices

Memory Mapped Devices: Device registers are mapped to physical memory.

IO Mapped Devices: Device registers are within the device itself. Requires special instructions (like inport, outport) to access those registers.