afr0ck

So, essentially, you're just doing cache eviction in software. That's obviously a lot of overhead, but at least it gives you eviction control. However, there is very little to do when it comes to cache eviction. The algorithms are all well known and there is little innovation in that space. So baking that into the hardware is always better, for now.

Well, it's not impossible. It's just software after all. You can mmap a remote device file, but you need OS support to do the magical paging for you, probably some sort of page ownership tracking protocol like in HMM [1], but outside a coherence domain.

I was once working on CXL [2] and memory ownership tracking in the Linux kernel and wanted to play with Nvidia GPUs, but then I hit a wall when I realised that a lot of the functionalities were running on the GSP or the firmware blob with very little to no documentation, so I ended up generally not liking the system software stack of Nvidia and I gave up the project. UVM subsystem in the open kernel driver is a bit of an exception, but a lot of the control path is still handled and controlled from closed-source cuda libraries in userspace.

tldr; it's very hard to do systems hacking with Nvidia GPUs.

[1] https://www.kernel.org/doc/html/v5.0/vm/hmm.html [2] https://en.wikipedia.org/wiki/Compute_Express_Link

That's what most hypervisors (e.g. Qemu) do on Linux when THP are enabled and allowed for the process.

> - Does it mean userspace is free to allocate up to a maximum of 1G? I took pages to have a fixed size. > - Or, you mean CPUs reserve TLB sizes depending on the requested page size?

The TLB is a hardware cache with a limited number of entries that cannot dynamically change. Your CPU is shipped with a fixed number of entries dedicated for each page size. Translations of base 4 KiB pages could, for example, have 1024 entries. Translations of 2 MiB pages could have 512 entries and those of 1 GiB usually have a very limited number of only 8 or 16. Nowadays, most CPU vendors increased their 2 MiB TLBs to have the same number of entries dedicated for 4 KiB pages.

If you're wondering why they have to be separate caches, it's because, for any page in memory, you can have both mappings at the same time from different processes or different parts of the same process, with possibly different protections.

> - Would memory allocators / GCs need to be changed to deal with blocks of 1G? Would you say, the current ones found in popular runtimes/implementations are adept at doing so?

> - Does it not adversely affect databases accustomed to smaller page sizes now finding themselves paging in 1G at once?

Runtimes and databases have full control and Linux allows per-process policies via madvise) system call. If a program is not happy with huge pages, it can ask the kernel to be ignored, as it can choose to be cooperative.

> If the dissertation is public, please do link it, if you're comfortable doing so.

I'm still in the PhD process, so no cookies atm :D

In current Linux systems, there are two main ways to benefit from huge pages. 1) There is the explicit, user-managed approach via hugetlbfs. That's not very common. 2) Transparently managed by the kernel via THP (userpsace is completely unaware and any application using mmap() and malloc() can benefit from that).

As I mentioned before, most major Linux distributions ship with THP enabled by default. THP automatically allocates huge pages for mmap memory whenever possible (that is when, at least, the region is 2 MiB aligned and is at least 2 MiB in size). There is also a separate kernel thread, khugepaged, that opportunistically tries to coalesce/promote base 4K pages into 2 MiB huge pages, whenever possible.

Library support is not really required for THP, but could be detrimental for its performance and availability on the long run. A library that is not aware of kernel huge pages may employ suboptimal memory management strategies, resulting in inefficient utilization, for example by unintentionally breaking those huge pages (e.g. via unaligned unmapping), or failing to properly release them to the OS as one full unit, undermining their availability on the long run. Afaik, Tcmalloc from Google is the only library with extensive huge page awareness [1].

> Do the heuristics used by Linux THP (khugepaged) really allow completely ignoring whether pages have actually been page-faulted in or even initialised? Is a possibility unlikely to happen in practice?

Linux allocates huge pages on first touch. For khugepaged, it only coalesces the pages if all the base pages covering the 2 MiB virtual region exist in some form (not necessary faulted-in. For example, some of those base pages could be in swap space and Linux will first fault them in then migrate them)

[1] https://www.usenix.org/system/files/osdi21-hunter.pdf

Because of virtual address translation [1] speed up. When a memory access is made by a program, the CPU must first translate the virtual address to a physical address, by walking a hierarchical data structure called a page table [2]. Walking the page tables is slow, thus CPUs implement a small on-CPU cache of virtual-to-physical translations called a TLB [1]. The TLB has a limited number of entries for each page size. With 4 KiB pages, the contention on this cache is very high, especially if the workload has a very large workingset size, therefore causing frequent cache evictions and slow walk of the page tables. With 2 MiB or 1 GiB pages, there is less contention and more workingset size is covered by the TLB. For example, a TLB with 1024 entries can cover a maximum of 4 MiB of workingset memory. With 2 MiB pages, it can cover up to 2 GiB of workingset memory. Often, the CPU has different number of entries for each page size.

However, it is known that larger page sizes have higher internal fragmentation and thus lead to memory wastage. It's a trade off. But generally speaking, for modern systems, the overhead of managing memory in 4 KiB is very high and we are at a point where switching to 16/64 KiB is almost always a win. 2 MiB is still a bit of a stretch, though, but transparent 2 MiB pages for heap memory is enabled by default on most major Linux distributions, aka THP [2]

Source: my PhD is on memory management and address translation on large memory systems, having worked both on hardware architecture of address translation and TLBs as well as the Linux kernel. I'm happy to talk about this all day!

[1] https://blogs.vmware.com/vsphere/2020/03/how-is-virtual-memo... [2] https://docs.kernel.org/admin-guide/mm/transhuge.html

Git pull the Linux kernel source tree (with lxr or cscope for code navigation). Open the Linux kernel mailing list, get some patch you're interested in (e.g. memory management), apply it to your tree, study the patch and participate in solving subsequent/related problems.

To me what you're saying sounds like slavery. Those immigrants are also humans, just like you, who may fall in love. If they lived 5/7 years in the US (for example, they did a PhD) and met someone and fell in love, it is inhuman and very stupid to me to expect them to think about it and possibly reject the love and the relationship just because they might loose their visa in the future. Imagine telling someone I can't be with you because I might not have a visa in 3 years from now and be kicked out of the country!!!

An immigrant has the right to live a life with dignity and not be deprived from human experience and oppressed and exploited just to have a chance to stay in the country and get a visa. What's shocking to me is that you think such a person is stupid!! Are you okay?

Thanks for the quote!

In this case, it is indeed novel to run the logic of the filesystem on the GPU itself. It's definitely worth the investigation!

I didn't fully read the paper, but few questions come into mind.

1) How does this work differ from Mark Silberstein's GPUfs from 2014 [1]?

2) Does this work assume the storage device is only accessed by the GPU? Otherwise, how do you guarantee consistency when multiple processes can map, read and write the same files? You mention POSIX. POSIX has MAP_SHARED. How is this situation handled?

3) Related to (2), on the device level, how do you sync CPU (on an SMP, multiple cores) and GPU accesses?

[1] https://dl.acm.org/doi/10.1145/2553081

8am to 5pm.

There is a pause from 12pm to 2pm.

Like many Mediterranean cultures, the people like to appreciate family/friends time and food and they always make sure to make those a priority. In other terms, not rich, but chill laid off people.

Overwork culture have no place and society doesn't encourage that in general. In my opinion, for two reasons 1) it's not a competitive society as in China or India, as there is enough resources for everyone. 2) Hard work is not properly rewarded as in the USA/EU, as the country suffers from corruption and it has failed to develop a modern meritocratic economy, so far.

We also get two hours in Algeria and la siesta is very common (generally known with its french name "la sieste"). I always took a siesta and I still take it to this day. It helps immensely with productivity. Giving up to a little nap after lunch gives a very refreshing and energising restart for the rest of the day.

Hibernation success also depends on device driver support and so many devices don't correctly support hibernation, for example, by failing to come back to life after machine is resumed, or certain functions becoming broken due to software/hardware bugs.

I agree with you, but, well, Google are not being very helpful in this instance.

Fair enough. Hope Google will do something about it!

Why don't you install a gate with a warning?

Haha Borat [1] was the first thought that came into my mind when I was reading the page.

[1] https://en.wikipedia.org/wiki/Borat

You're implementing a Slab allocator. That's exactly what any Slab allocator does, including gmalloc, tcmalloc, jemalloc and SLUB (Linux kernel). But, there is probably much much more you can do on a modern machine to squeeze even more performance. Some of the things that comes into my mind are: reducing tlb stalls with hugepage awareness[1], and reducing false cache sharing on SMPs [2].

For the compression part, have you thought about OS-managed memory compression [3][4]?

[1] https://google.github.io/tcmalloc/temeraire.html

[2] https://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemal...

[3] https://dl.acm.org/doi/pdf/10.1145/3297858.3304053

[4] https://www.kernel.org/doc/Documentation/vm/zswap.txt

I just keep applying to relevant jobs. I, personally, have very specific requirements that makes it much harder for me to find relevant jobs.

Fellow Kabyle from Béjaïa borders here. I'll definitely try to recreate some of these recipes!!

It happened to me, today. She kept me waiting in a call booth for one hour.

The kernel page cache is an XArray [1] (data structure here [2]) and dirty page pointers are annotated with the dirty tag when the page is dirtied [3]. There is a per-filesystem callback that usually always ends up here [4], where you can see the the above data structure [2] entry for that page is being tagged as dirty.

Edit: fixed typo

[1] https://docs.kernel.org/core-api/xarray.html

[2] https://elixir.bootlin.com/linux/latest/source/include/linux...

[3] https://elixir.bootlin.com/linux/latest/source/mm/page-write...

[4] https://elixir.bootlin.com/linux/latest/source/mm/page-write...

There is the Berkeley BOOM core as well [1], which is more interesting to me. [1] https://github.com/riscv-boom/riscv-boom

From a tech-nerd point of view, here is the reason why I am so excited about RISC-V. RISC-V means there is a possibility of creating a completely open source implementation of an industry-grade microprocessor, just like the Linux kernel did for operating systems, democratising the business of building advanced microprocessors. I can't work for Intel or Arm design teams. Hardware is not my main job and entry barrier to those companies is so high (without mentioning age and geographic barriers). However, I would have loved if there was a real, industrial, free and open implementation of a microprocessor where you collaborate with smart people all over the world to solve interesting problems and implement advanced hardware designs and algorithms.

If the oom-killer is called, you'll see something on dmesg.

Swap (Disk, RDMA, Compression)? Page migration (NUMA, CXL)?

In my opinion, it's all market economics that decide how things work. The moment you introduce a complex courting procedure, where maintainers are required to be nice and acknowledge every little detail and guide the newbies through every half-baked contribution, you'll kill the project. That's because what keeps the maintainers and the senior contributing and maintaining is the technical work and not the human work. Most maintainers would rather spend their time exploring, contributing and doing technically useful stuff than making every newbies happy and welcome and teach ing them to be smarter and better developer. Such a project will automatically loose the ultra smart, self-driven people that keeps projects like the Linux kernel relevant for more than 30 years. It's all market economics.

Again as I said, maybe "Reported-By" was not the most correct tag, but it still attributes some form of credit to the newbie. I just think that's too much woke culture and self entitlement from the newbie. You just have to work harder and up your skills to match the maintainer's standards before you can be called a kernel hacker. One or two patches, imho, is not enough to be called a kernel hacker, especially when it's only about fixig a bug. I fixed many similar obscure bugs. Writing a precise algorithm for Automatic NUMA balancing is a true kernel challenge for which one deserves to be called a kernel hacker.

When I started contributing to the kernel, it was super painful and I failed multiple times. I got super harsh comments (someone called me "retard. It was fun, I laughed, eventually part of my work gor merged) but I always respected the maintainers and I was eager to better myself and improve my analytical and development skills with an open mind to be as sharp as the senior hackers. I always looked up to them and never thought in the same way the newbie did when my patches got re-written or dismissed. I just considered myself "not good enough" and I felt "I had to work harder and smarter".

Seeiously, what are you expecting from Michael? Go back and forth with the newbie until he makes a perfect patch? Sorry, but that's bullshit and clearly a horrible use of a maintainer's time. Michael did his best by fixing the patch and incorporating into the kernel and properly giving credit to the newbie by using the "Reported-By". The fact that there isn't a proper tag to describe the newbie's case is not Michael's fault. Maybe the kernel should add a "Debugged-and-fix-suggested-by", but I also think this is bullshit.

US is literally built on immigration!! Millions of Germans, Italians, Japenese, Persians, Chinese, Indians immigrated to the US since the 18th century.

Benjamin Franklin was very worried about German immigrants in the US and he described them as "less intelligent", "aliens" and that they won't assimilate. Fast forward few decades later/centries later, Germans are one of the most successful immigrants group in the US, industrialising the country, creating financial institutions, and becoming military and political leaders, giving US presidents and generals. Recently, Asian immigrants created Silicon companies. One of them is a trillion dollar company called Nvidia.

France has a huge success story with immigrants as well, the poles (Marie Curie), the Italians, the Portuguese, North Africans, etc.

There are certain issues here and there, especially with unregulated modern mass migration, but in my opinion, that's not a true representation of real immigration that has always happened since the beginning of time.

The fact that Sweden has integration issues with mass migration from war-torn Syria is a special case.