Lets the goal of the model here. The model takes the tokens seen so far, runs attention over those context tokens build a representation of the current state, and then outputs logits: one raw score for each token in the vocabulary. Those logits represent how likely each vocabulary token is to be the next token.

Lets now divide this process into steps that require to produce an output token.

• Encode

  • Takes in the input text and converts it into token ids using a vocabulary tokneizer

  • For the words that do not have a corresponding token id we have some unknown token ids that can be returned for example “<unk>”

  • The output is a dictionary that you can use to convert each token into token ids

• Decode

  • This is pretty straightforward this step is usually done at the end. This converts the token id back into the word to output.

• Forward Pass

  • The forward pass takes the token ids seen so far and produces logits

  • Basically you take all the input tokens put them in the array and give it a score based on the logits that the model has prepared. This is the part we assume for the purposes of this article is a black box (Part of the model generating these logits using attention mechansims)

  • In the forward pass you create an array of the predicted words with its respective logits, these logits are raw scores for every possible next token in the vocabulary.

• Softmax and Temperature

  • Once you have the set of logits they are not a set of probabilites so we need to be able to convert them into probabilities for which you need the softmax function.

  • You can read about softmax here. https://en.wikipedia.org/wiki/Softmax_function

  • These set of probabilities are now easier to reason about and predict the next token against.

  • We have another concept here called as temperatures temperature controls how random the next-token selection is. We apply it by dividing each logit by a value T before softmax.

    • If T < 1, the distribution becomes sharper. The highest-scoring tokens become even more likely.

    • If T > 1, the distribution becomes flatter. Lower-scoring tokens get more chance, which can make the output more varied or creative.

• Sampling:

  • Once we have probabilities, we sample the next token. We pick a random number between 0 and 1, then use the cumulative probability ranges to decide which token gets selected.

  • For example, if the probabilities are [0.1, 0.2, 0.7], the ranges are:

    0.0 to 0.1 -> token 0

    0.1 to 0.3 -> token 1

    0.3 to 1.0 -> token 2

    A token with a larger probability owns a larger part of the 0 to 1 range, so the

    random number is more likely to land on it.

This is the basic loop of inference, i have a small github repo where i will upload the code for this, but this is the gist of it. In the future lets keep building on this base.

Intuition behind needing these operations: You see in a GPU which is a graphics processing unit, cores are at a premium, the cores are what do the heavy operations inside, read the matrix multiplications i.e the very core operation inside an LLM. Keeping the internal architecture of the LLM for a different discussion i want you to understand that Prefill is an expensive operation it is the operation that uses a lot of the GPU to run the prompt tokens through the model using the existing weights to compute the hidden states its attention outputs and most importantly, keys and values for the KV cache

Decode on the other hand is an operation that is sequential because it is generate for every token and hence, its less parallel and usually uses one token at a time and is often more memory-bound rather than compute bound

There is an important pre-req that i have left out of this discussion is the KV cache, but I feel I would be doing injustice to this entire concept if I explained that earlier. We would need to spend some time understanding the internal workings of a an LLM first

Why cant they be run concurrently ? For a single request, prefill must happen before decode because decode depends on the prompt’s computed state and across many requests, inference engines may interleave prefill and decode, but doing so efficiently is hard because the two phases stress the GPU differently and therefore we need to

Diagram:

Life has meaning even in extreme situations
Victor Frankl dives deep into this idea of how a human can have meaning even in the most dire of situations, and how man can choose how you feel about certain things when life can get really hard. My takeaway from this is no matter how hard things get or whatever your going through, we might not have extreme control or any control at all over it, its really important to have a purpose beyond the situation, like a future goal, a task, or even something that you want to achieve, which might make the situation a bit more tolerable in the current moment.

The collapse of the why
In the book victor introduces us to idea of a “will to meaning” which means that most people suffer not from a lack of comfort but from a lack of “Why”. When the why collapses people start to feel empty, depressed, and other such feelings. The author calls it “existential vaccum”. My takeaway from this idea is to achieve something special you do not need motivation, all you need is a strong why. The answer to the question of what to pursue in life comes from the why. Its a very common reason as to why you see a lot of the people go through a large portion of their lives without any purpose and then reach their late 30s and realize that they do not have a strong why to their. Mid-life crisis and its very idea has its foundations in the lack of why.

Three main ways we find meaning
The author says there are three major sources of meaning.

• By creating or doing something.

• By experiencing something or encountering someone

• By the attitude we take toward unavoidable suffering

Between the three i think the one that speaks to me the most is the creating or doing something. The ability to express my creativity is one of the most thrilling experiences. I am an engineer by profression, so coding and playing around with computers is what i do for a living. Being able to learn, understand an deep dive into concepts is what brings me the most meaning. So thats my takeaway from this idea.

Tragic optimism
The last idea that i wanted to touch upon, is no matter what youre going through having an attitude of learning and believeing that its going to be all right is the foundation of the idea of tragic optimism. For example doing something wrong can teach you about not repeating that thing again. Understanding that this present moment of hardships is just a learning opportunity for the future.

• Every process has its own task struct. And in that task struct is basically a field which is a pointer to struct called file_struct

• File descriptor table lives as a filed inside this file_struct as fdtable which is a growing array of struct_file*

• Dentry (directory entry) is an in-memory record that maps a name inside a directory to an inode.

So in this blog we are going to be diving deeper into the structures of these tables.

So the columns in the file descriptor table are two fold one is the list of file descriptors which as I explained in the previous blog are integers from 0 to per- RLIMIT_NOFILE per process.

Open File Description Table

Each entry in the file descriptor table maps to a struct file which is basically an open file description. This points to an entry in the open file descriptor table which is like a table consisting of all of the file entries currently. Internally it is just a collection of all of the open file descriptors that each individual file descriptor of a process points to.
struct file holds the offset (f_pos), status flags (f_flags, e.g., O_APPEND, O_NONBLOCK, O_SYNC, O_DIRECT) and access mode (f_mode). I will go into what these flags are in part 3 but for now all you need to understand is that each flag has its set of status falgs that its opened with.

Inodes

Each entry in this open file descriptor table points to the underlying inode inside the file system. Each FD points to a struct file. That struct file has an f_path (mount + dentry). We will deep dive into dentries in another blog, you can look it up or ill put it in the pre-requisites up top. The dentry references the inode. The inode does not store a path; paths are names in dentries The inode holds file metadata: permissions, owner, size, timestamps, device/superblock links, etc.

In the next blog we will dive deep into how dup, dup(2) works on duplicating these file descriptor and how offsets are dealt with as well as wrap up the knowledge we need for these file descriptors.

What are file descriptors ?
They are positive integers starting from 0 all the way to the maximum file descriptor integer. Imagine a process want to open a file, when it calls the open syscall and it assigns an integer in its file descriptor table. It chooses the lowest possible integer available. Once they do this they now have a way of referencing that file in their file descriptor table

How many FDs can I open?

• Per-process: ulimit -n

• System-wide: /proc/sys/fs/file-max.

Why do we need file descriptors ?
There are multiple ways that a process can interact with a file in linux. Processes can read a file, they can write to a file, they can append to a file. These file descriptors help the system keep track of the files they open close and have access to modify.

Standard File descriptors (0,1,2)
There are three important file descriptors in a linux file system. 0,1,2 are the FDs for the stdin, stdout and stderr. So basically processes use these numbers to either take input, or write out to the terminal. Sometimes they can point to a file as well, but that means that means there is some shell redirection happening. These three FDs are reserved for output and input

Next part
We will look at how the file descriptor table looks like and how syscalls interact with the file descriptors.

I definitely highly recommend this book to all fiction readers, and definitely cannot wait for the movie. Jazz hands !

Pre-requisites

• User space and kernel space: Linux runs applications in two modes, one is the kernel mode which is the most privileged in terms of permissions and the user mode which is the least privileged. System calls run in kernel mode is something that is an important pre-req to understanding how they trace

• Traps: There is something called as a trap in a linux kernel. This is kind of like a synchronous CPU exception where we transfer control from the user space to the kernel space. These are different from interrupts are asynchronous and come from hardware

Step 1: Transfer from a user space to a kernel space
When python makes the write() call it calls in to a libc `write` wrapper which loads the syscalls and the values into registers and then executes the syscall. This point is the main transfer interface to a kernel level space.

Step 2: Trapframe and copying of user register
On entry, the kernel saves user registers into pt_regs (the trapframe) so it can return or deliver signals later. This is basically a snapshot of the user context. It generates this so that it can restart syscalls if needed, return to the user context if needed, or deliver signals

Step 3: Execution of the syscall and returns control
We now have all the steps in place, the kernel then executes the appropriate syscall after reading from rax and then calls the —x64_sys_write. This then resolves to vfs_write which is the virtual file system call. Now it needs to copy the buffers and does so with (copy_from_user). With all the values it requires and then writes the buffer at the correct position. Once that is complete it returns control using sysretq and puts the return value back in rax.

Note: This is just a high level trace of the write system call and there is a lot of depth to be covered, but its a great introduction to understanding the execution of a syscall.

Print statements are the fastest way to see what your code is doing.
Use a small set of repeatable print patterns to expose inputs, branches, loops, recursion depth, and thread order in multithreading examples.

When i started programming one of the things that helped me majorly was the ability to add print statements anywhere. New programmers get stuck because code feels invisible. When you start out programming most of the programs you can write will have stuff that you can print out for example, just as a preface i wanted to mention that incase you did not want/or necessarily bog yourself down by learning to use a debugger you could reduce that friction by using print statements. I plan to enunciate this concept with a few use cases.

Quick print tips that help across all use cases:

• add labels so you know what a number/string belongs to: print(”i:”, i) not just print(i).

• make the prints easy to scan: use short prefixes like [STEP], [EDGE], [OK].

• show both the value and the type when you’re confused: print(”x=”, x, type(x)).

• for strings or whitespacey stuff, show the repr: print(repr(s)) so you can see hidden chars.

• when order matters, include a simple counter or timestamp.

Use Case #1 Trace values for pattern spotting
Write a program to test whether a given string has a palindromic substring
You can probably one shot this program using an LLM nowadays, but the goal here is to learn. so as you probably go through the problem one of the ways would be to prints all substrings, look at them visually and then see if you spot patterns. Once you spot a pattern you will probably be able to code it out. Now that code might have bugs, so one of the way you can probably start to debug that is voila Add print statements and figure out why is the edge case not what you expect.

Use Case # 2: Print recursion depth to make call order click
Recursion is a concept that a lot of programmers struggle to get their head around.A simple hack is to put down a print statement in the parent function and the function you plan to recurse over. And add something like print(“Printing from current function”). This will give you a picture in your head on the sequence of instructions getting executed. Our brains love to see sequential ordering and having print statements will let you visualize this .

• What: Add depth markers and entry/exit prints in recursive functions.

• Why: Humans love sequences and depth shows the stack growing and shrinking. With arrows and indents, we can literally see “go down, come back up,” which fixes mental models fast.

Use Case #3 Timestamp threads to spot flow of threading
When learning programming an important concept that we learn, and just for context, multithreading is when you run a program using multiple threads so that the work that a single thread can do is now being done by multiple threads and the coder can then either consolidate those results or use them individually. The hard part here is sometimes figuring out bugs, and one of the ways to do it is to plug in print statements for what you expect to happen at the end for example.

• What: In multithreading, add thread name + timestamp to prints.

• Why: Timestamps reveal unexpected order

Food for thought

• Where did a print-first approach save you time when you first started programming.
  
  

I read Anthropic’s post on context rot and turned the ideas into things I can ship. Below are the 4 changes I’m making to keep agents sharp as context grows

Compress to high-signal context
There is an increasing need to prompt agents with information that is sufficient to do the task. If the context is too long agents suffer from attention span deficiency i.e they lose attention and seem to get confused. So one of the ways to avoid this is to ensure the context given to the agent is short but conveys a lot of meaning. One important line from the blog is: LLMs are based on the transformer architecture, which enables every token to attend to every other token across the entire context, This results in n² pairwise relationships for n tokens. (Not sure what this means entirely ) . Models have less experience with long sequences and use interpolation to extend

Ditch brittle rule piles
Anthropic suggests avoiding brittle rule piles rather use clear, minimal instructions and canonical examples (few-shot) rather than laundry lists in the context for LLMs. They give example of context windows that try to gain a deterministic output from the agent which leads to further maintenance complexity from the agent. It should be flexible enough to allow the model heuristic behaviour. The blog form anthropic advises users to use markdown headings with their prompts to ensure separation, although LLms are getting more capable eventually.

Use tools as just-in-time memory
As the definition of agents change we have noticed that agents use tools to load context into their working memory. Since tools provide agents with information they need to complete their tasks we notice that tools are moving towards becoming just in time context providers for example load_webpage could load the text of the webpage into context. They say that the field is moving towards a more hybrid approach, where there is a mix of just in time tool providers and a set of instructions at the start. Having to go through a file such as `agent.md` that would guide the llm on what tools it has at their disposal and what structures contain important information would allow the agent to avoid dead ends and waste time in exploring the problem space by themselves.

Learning Takeaways

• Compress to high-signal context.

• Write non-brittle system prompts.

• Adopt hybrid context: up-front + just-in-time tools.

• Plan for long-horizon work.

If you run have tried things that work reply with what you;ve learnt.

• Make a mental map of the functions:

  • When your going through the code always try a high level outline of the file and then build on that towards. Like for example, start at the top of the file and go through the functions clicking on them to go towards the source code

• Run the code through a debugger :

  • One of the underrated ways to understand a codebase is to run the code that you are reading through a debugger. Attach a breakpoint and the simulate running the code, you will understand the flow of the code extremely well.

• Start from the test cases:

  • If the project has test cases, that’s your entry point. Run them and watch what happens.

    • What objects are being created?

    • Which functions are called first?

    • What files are imported?

Learning to read code well takes time. You won’t understand everything the first time and that’s okay. But if you repeat this process across 3/4 small projects, your brain starts to see code structure naturally.

Goroutine scheduler: The scheduler’s job is to distribute ready-to-run goroutines over worker threads.

When you write go f(), the go compiler and runtime arrange to do the following:

• It allocates a small descriptor for the goroutine and a small initial stack

• Records the entry function f and its arguments in that descriptor

• Place this new goroutine onto a run queue so it can be scheduled.

Lets understand what is the schedulers basic model

• G = The goroutine which has the function the stack and the metadata

• M = The OS thread that actually runs code on a CPU core

• P = The processor that allows an OS thread to run code. It owns queues of go routines.

Diagram

How does your function actually get time ?

1. go f(x) compiles to a call into the runtime that:

   • allocates a G with a small stack (growable).

   • records entry f and its args.

   • pushes G onto the current P’s local run queue (or global if needed),

   • may wake/start an M if there’s idle work but no running worker.

2. An M that owns that P runs the scheduler loop:

   • pop a runnable G from the P’s local queue (or global / steal).

   • switch to the G’s stack and call f.

   • preempt/park on syscalls, channel/blocking, GC safepoints etc.

3. If a goroutine blocks (syscall/channel), the M may park or hand the P to another M so the run queues keep draining.

Historical breadcrumb:

• In older Go sources (e.g., Go 1.1 era), you’ll see the same idea in functions like startm/wakep: when a G becomes runnable, the runtime tries to ensure a P has a running M so work doesn’t idle.

• If you peek at today’s runtime/ code, search for newproc, schedule, runq, and startm in proc.go names are readable even if details changed.

Goal: deliver every unique message to every node.

In a multi node broadcast system we need to ensure that a message is broadcasted over an entire system. The first idea that came to my mind was pretty simple, when we get a value that is broadcasted, we gather the nodes in the topology that are neighbors of that node and then send to all the neighbors in the list. Pretty simple right and your right it is.

Note: When you send a message to a node it sends back a broadcast_ok message back, this is an important piece of information.
I did not check for this message, all i did was fire off and forget, which was a grave mistake on my part.

Steps

a) Receive a broadcast message
b) Iterate through the neighbors
c) Send broadcast message to all neighbors

The diagram below makes it simple to visualize.

Catch

The way the challenge is designed it is totally possible that due to a network partition that a node does not send the broadcast message and in that case since the way we have designed the system, we do a send and forget, which clearly did not work in our chase. So the next challenge is to figure out a retry mechanism or some sort of a worker that will retry messages that are not getting broadcasted.

Side Notes

• Command: maelstrom test -w broadcast --bin ./your_bin --time-limit 20 --node-count 5 --rate 100

• Expect: no missing deliveries, no duplicates, stable latency

• Example passing line: :valid? true :lost 0 :duplicated 0 :unexpected 0

Takeaway

• Idempotency first (dedup), then reliability (acks+retries), then healing (anti-entropy).

The set of messages are a steady stream and they could be of the order of a thousand messages per second.

Architecture

Approach

All we do is when we receive a broadcast we just store those values in a global list and then return that list when asked for it. Every node also has its topology i.e it has information about its neighbors where it can store data for that particular node.

Next step: Multi Node Broadcast system:

Our node should propagate values it sees from broadcast messages to the other nodes in the cluster. It can use the topology passed to your node in the topology message or you can build your own topology.

Problem statement: Generate a cluster wide unique id, assume that this unique id is provided by a service. This service is replicated on a cluster of nodes each one being stateless. During increasing load this service can get called multiple times (10,000 times a second) , increasingly so even at the same time.

Lets explore some ideas of how we can think of this problem.

Idea 1: Keeping a global set of ids

This is sort of the first idea that comes to mind. You can ensure uniqueness by just creating a global set of unique integers. We can use random number generator with a seed to spit out a random number. When your random number generator generates a random id you could go check if it exists and if not just insert it in our global set.Easy peasy.

Caveat: The caveat here is that two nodes could be called at the same time, causing our global table to accessed at the exact same time, since one of the nodes would determine that the key that it is looking for does not exist. We could ensure atomicity by locking the data structure which could be an alternate solution i could have explored but for the simplicity of this exercise I did not go down that route. But it could be an interesting discussion.

Approach 2: Using the unix microsecond timestamp
This approach came next to my mind. We could pull out a unix microsecond function from any language, that would allow us to be more globally unique since it would take the current timestamp and then convert it into a unix timestamp in microseconds which is an extremely small unit . Return this timestamp to the caller and voila, we have a unique timestamp. This makes the code cleaner and eliminates the unique set we need to keep. Minor win.. or is it ?

Caveat: in this approach like the last one it could be possible that the function is called simultaneously at the same microsecond (which is thought is unlikely but just assume we have an extremely popular service), therefore it could generate the exact same value, leading to duplicates. At this point its pretty clear we need to have some sort of combination of approaches.

Approach 3: Combination of microsecond timestamp and a process counter.

I needed to do some googling to come up with this one. It was not so obvious to me. This approach involves using a shared atomic counter seq that auto increments and would guarantee uniqueness across processes. Let take an example.

Node 1: Timestamp: 10, Shared counter: 1, Final ID: 101
Node 2: Timestamp: 10, Shared counter: 2 , Final ID: 102

We can do some mathematical operations like OR and bitshifting to get a unique iD but this one is the most simple. Take the two timestamps, convert them to strings and then concatenate the strings to get the unique id. In concurrent processes or processes with multiple threads this comes handy.

Note:

In Go, the statement c := atomic.AddUint64(&seq, 1) uses the sync/atomic package to safely increment a shared 64-bit unsigned integer (seq) and return the new value.

Additional pointers:

• We could have used the node id if our service maintains something like that to ensure uniqueness since the node id would be different for each node.

• Mathematical operations like OR and bitwise shifting for the last approach are perfectly valid solutions for this problem

• I have not explored the idea of atomicity of the database for ID generation, perhaps we would be able to guarantee atomicity and consistency but I did not give it much thought. Would love to hear any ideas if you have any.

I found myself in that rut probably after I joined my full time job at the end of 2023. The struggle and hard work during my grad days was replaced by something a bit more mundane and stable at my workplace. I found myself substituting that with a less harder things that satisfied my dopamine hit. Fast forward a couple of months and even reading a wiki that was moderately hard became an absolute nightmare, meaning the things that needed to get done were getting put on the back burner.

At that point i realized i need to develop a bias for action, or put simply just doing things. I came up with a few points that i will share with you that helped me get out of that rut of inaction

• If it takes less than 15 minutes to accomplish something do it now. Things like ordering stuff on amazon, filling out an important document, applying for a drivers license etc. The boring things that we tend to procrastinate come in this list that could get done in small blocks of allocated time.

• Then I started with things that are the highest priority, things that if not done would have dire consequences over a long period of time. The tasks that got assigned to me at work. Filing taxes, ensuring all the bills etc are paid on time. These are the kind of things that need to get done regardless and require the most amount of time and focus.

• Then I started taking decisions that would not have long term consequences a bit faster. Not sure what table to order. ChatGPT it, pick the top 2 and go with one, we can return it later if we do not like it. Write that new blog, as if no one is reading, we can refine it later. These activities are those which require some sort of decision making which we either postpone due to lack of knowledge to take that decision or just the sheer number of options. If its the later then read the next bullet point.

• For the deicions that need more evidence or data poitns, I tend to put it down in my todo list and then come up with a set of points that I need to take that decision and then i go back to point 1 of this post and work my way down until i either end up with the task done or a set of data points that i need to gather and work on.

I hope this blog helped and feel free to leave any comments about the techniques you learnt or use that help you to take action faster.

The primary audience for this is new engineers joining teams in a new company, i would try and keep this tailored for engineers in tech. But I think the major principles or themes can be borrowed and used anywhere.

Get a name on your first meeting

On your 1:1 with everyone on your team, after your introductoin with them and general chichatter, just before you thank them for their time, get two names or at least one that you should definitely talk to in order to understand stuff better.

You then keep going down the list given by everyone. You do not have to go all the way to the bottom, you might end up talking to the whole company.

Just a 4-5 interations below the first person and you should be good to go.

Search for todo items in your codebase

The best way to get familiar with a codebase is to solve small issues or solve problmes that no one has the time to get to. Just open up VSCode and in the "search all" bar type TODO: and you should get a bunch of TODOs that engineers have left. and then you just start solving them. Make some PRs that solve them or ask if you need more context, this will enable you to move fast and gain real skills while building credibility on the team.

Take a while to sit back and observe

I know its pretty tempting to join a new team and wanting to make an impact and prove yourself. But you have to remember the team you are joining might have been around for a very long time with team dynamics already set. Don't be afraid to make your voice heard but also ensure to maintain a balancing act to be too pushy about solving things "your" way. Feel free to observe, learn and ask as many questions as you can to know why the thing you are suggesting might not be practical at this point in time.

Threads in java are just a wrapper around the actual operating system threads. The JVM requests the operating system to create a thread. Each thread in java has its own components like program counter, call stack etc. There are two types of threads, in the JVM one is the native thread and the java thread. The native thread is the thread that the OS controls to perform various types of operations like controlling internal hardware operations etc.

Are threads expensive ?
Each thread in Java has its own call stack, which is used to store the state of the thread as it executes. When a thread is created, a new call stack is also created for that thread, and this can consume a significant amount of memory, especially if the stack frames are large

What is the solution

Java 16 came up with the solution of virtual threads. A virtual thread stores the stack memory on the heap instead of the stack, allowing it to allocate more memory.

Let us see an example on how to create a virtual thread.

public static void main(String[] args) {
        ExecutorService executorService = Executors.newVirtualThreadExecutor(new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
                return Thread.ofVirtual().start();
            }
        });

        executorService.submit(() -> {
            System.out.println("Hello from virtual thread!");
        });

        System.out.println("Hello from main thread!");

        executorService.shutdown();
    }

In this example, we create a new ExecutorService that is configured to use virtual threads. We define a ThreadFactory that creates new virtual threads using the Thread.ofVirtual() method, which returns a new virtual thread that is ready to be started.

We then submit a new task to the executor service, which will be executed on a virtual thread. The task simply prints a message to the console.

How virtual threads work internally ?

The JVM maintains a pool of platform threads. This is known as the forkJoinPool. This pool contains a pool of around 256 threads which is the maximum limit. It usually depends on the number of cpu cores. When a virtual thread encounters a blocking operation, such as waiting for I/O or a lock, it will block and suspend its execution until the operation completes.

When this happens, the virtual thread's stack chunk (the portion of the stack that the virtual thread is currently using) is copied back to the heap, which frees up the carrier thread to execute other virtual threads that are ready to run. The carrier thread is the underlying thread that is executing the virtual thread's code, and it is responsible for running multiple virtual threads concurrently.

Once the blocked virtual thread finishes the blocking operation, the scheduler will schedule it again for execution. This can happen on the same carrier thread or a different one, depending on the scheduling policy of the virtual thread pool.

In the next part we will take a look at scheduling and how virtual threads are pooled together.

What is a Page in linux ?
A page is a fixed block of physical memory that the kernel uses to manage various operations. The typical size of a page in linux is around 4KB. It allows for efficient use of physical memory by sharing it among multiple processes and by swapping unused pages to disk when memory becomes scarce.

How is a page cache and how is read and write to a page cache done?
A page cache is linux’s way of accessing memory quicker. Generally if a the kernel wants to read a file it first checks if that file has its data in the page cache. If yes it can avoid the expensive operation of reading that data from disk.

How reads are done to the disk

• When a user-space application wants to read data from disks, it asks the kernel for data using special system calls such as read(), pread(), vread(), mmap(), sendfile(), etc.

• Linux kernel, in turn, checks whether the pages are present in Page Cache and immediately returns them to the caller if so. As you can see kernel has made 0 disk operations in this case.

• If there are no such pages in Page Cache, the kernel must load them from disks. In order to do that, it has to find a place in Page Cache for the requested pages. A memory reclaim process must be performed if there is no free memory (in the caller’s cgroup or system).

How writes are done to the disk

It is the same as how reads are done but the only difference is the writes are not written immediately to disk. What this means is that the pages are just written to and are kept that way until a page flush occurs. The data that is not yet flushed is marked by the kernel as dirty pages.

The first thing that happens working with system calls is that the process first switches from user mode to kernel mode. When in user mode the OS is executing user level instructions and in order to execute kernel level instructions it would need certain elevated privileges.

Step 1: The system needs to switch to the kernel mode and for that to happen, the wrapper puts the system call into a specific register. We have a sys-call table which identifies the system call by a unique identifier.

Step 2: The system then executes a trap instruction which switches the system from the user mode to the kernel mode and then begins executing the code at location 0x80 of the systems trap vector.

Step 3: Now that the instruction is in memory in response to the trap instruction it makes a system_call() with certain parameters to handle the trap. This handler does certain things

• Checks for the validity of the system call

• Saves register values on the kernel stack (We have two stacks inside an OS one is the kernel stack and one is the user stack)

• Checks for the arguments in system call, if the memory calls are valid and not out of bounds.

• After the sys-call has returned it makes the appropriate changes to the registers and then puts the return value back onto the stack, to be returned back to the wrapper.

• Returns the processor back to the user mode.

Step 4: If the return value of the system call service routine indicated an error, the wrapper function sets the global variable errno using this value. The wrapper function then returns to the caller, providing an integer return value indicating the success or failure of the system call

• ls: The ls command can be used to list files.

  • ls -a lists all the hidden files as well

  • ls -R recursively lists down all the files in the subdirectories.

  • -t option will sort the entries by modification date

• cat: It is used to list the contents of the file.

  • -n : Lists the contents of the file along with the line number.

  • cat fileOne fileTwo : Copies contents from file one to file two

• tail: It is used to print the last 10 lines of the file.

  • It can be used to continuously watch changes to a file

• chmod: It is used to change file permissions in linux

  • The digits 7, 5, and 4 each individually represent the permissions for the user, group, and others, in that order. Each digit is a combination of the numbers 4, 2, 1, and 0

• grep : It is used to search regex in the file structure

• ps: It is used to list processes.

  • ps -A: It is used to list all the running processes.

  • ps -p p_id: It is used to list the process with a given pid

  • aux: It displays a list of information you might need on how the different information reported by various lists of processes.

• top: It is used to monitor the vitals of the system and can give you an overview of how your system is performing.

• wget: It is used to download files from the internet.