IRC channel logs

<oriansj>one can build all of Rust on an x200 with 8GB of RAM (and about 10GB of swap); it just takes about a week

<GoogulatorMobile>oriansj: was this you posting a long time ago? https://forums.wz2100.net/viewtopic.php?t=9652

<oriansj>Googulator: nope

<oriansj>and I added support for return 1_000_000; to be valid in M2libc's parsing of integer strings and M2-Planet gains it for free.

<oriansj>and updated M2-Planet's tests to fix the breakage of the M2libc/sys/utsname.h change

<oriansj>but I do wish they posted a copy of their work online for audit and verification.

<oriansj>or constructions such as 0xCD_FA_AA_B7 or 0b11110000_00001111_11001100_00110011

<oriansj>(I got the idea for how to do it from the crowbar programming language)

<oriansj>we can't use it in M2-Planet or mescc-tools (due to it not existing in the hand written hex2, M0 or cc_*) but it can be used in anything after that if one wants to break out the bytes for clarity or make things look nicer.

<Googulator>oriansj: "one can build all of Rust on an x200 with 8GB of RAM (and about 10GB of swap); it just takes about a week" - ouch, that sounds scary

<Googulator>I wonder what systems can even do more than 8GB without using components newer than 15 years, if any

<Googulator>LGA-1366 apparently can go up to 24GB (thanks to its 3-channel memory controller), and it just barely squeaks under the age limit

<Googulator>Mikaku: I'll check out your patch, but I still think my solution is better, since it actually clears up confusion related to whether the end address is exclusive or inclusive.

<Googulator>Also, my PR fixes the extra reservation which, as I understand, is only necessary within Fiwix, while the kexec guest (Linux in this case) should be free to use it.

<Mikaku>Googulator: what do you mean by exclusive or inclusive end address?

<Mikaku>regarding the extra reservation address range, you're right, it shouldn't be passed to the kexec guest

<Googulator>There are 3 conventions for representing memory ranges:

<Googulator>- start address, length

<Googulator>- start address, address of last byte in the range (aka "inclusive end address")

<Googulator>- start address, address of first byte outside the range (aka "exclusive end address")

<Googulator>E.g. 1 gibibyte of memory starting at 0x100000 is [0x100000, 0x10000000] using the start-length convention, [0x100000, 0x10100000] using the exclusive end address convention, and [0x100000, 0x100fffff] using the inclusive end address convention

<Googulator>The BIOS E820 interface uses start-length, while both Fiwix and Linux log the memory map using the inclusive address scheme

<Googulator>However, actual uses of the memory map in Fiwix seem to use a mixture of inclusive and exclusive convention

<Googulator>risking off-by-1 errors

<Googulator>My PR makes everything consistently use inclusive end addresses

<Googulator>is_addr_in_bios_map (the only function in Fiwix that reads the memory map for any purpose other than Fiwix) uses the < operator to compare an address to the upper limit, which is correct if the upper limit is an exclusive end address

<Mikaku>I see, well, with my patch the original address aren't touched and the inclusive addresses are only for printk(), internally they are exclusive address, so the use of the < operator in comparison should be correct

<Mikaku>this is the same line as mmap() does, except that the file /proc/self/maps uses the exclusive convention to be aligned with Linux

<Googulator>Using exclusive everywhere (except for printing, to align with Linux) is also a good solution, just make sure it's indeed consistent

<Mikaku>it wasn't as you discovered in the bios_mem_map[], but I believe my patch solves it without having to duplicate the same array

<Mikaku>what my patch doesn't solves is to avoid to pass the extra reservation to the kexec guest

<Googulator>yeah, it does look like it makes the scheme consistently exclusive

<Googulator>As for the duplication, I think it is probably needed, although I chose some unfortunate names

<Googulator>orig_bios_mem_map (the new one) should just be bios_mem_map, while bios_mem_map (the existing one) should be kernel_mem_map

<Googulator>this is better in the future, because the kernel is free to additionally modify kernel_mem_map for its own needs (e.g. removing 4GiB+ addresses, reclaiming ACPI reservations, etc.), while bios_mem_map continues to accurately represent the BIOS's view of the memory map

<Mikaku>Googulator: yes, bios_mem_map for the original and kernel_mem_map for the current one are much better names

<oriansj>Googulator: well there are PAE server systems which had 64GB of RAM but those old Xeons were (and still are) massive power hogs

<Googulator>PAE doesn't really matter, because by the time all that RAM is needed, we have a 64-bit kernel anyway

<Googulator>LGA775 appears to max out at 16GB, although only 8GB is consistently supported on all mobos

<Googulator>LGA1366 has been shown to max out at 48GB for both consumer and server parts

<Googulator>now the question is, can we find memory modules manufactured before February 2009 in that size

<Googulator>(although I guess newer memory isn't as dangerous as a too new motherboard would be)

<oriansj>Googulator: you want PPGA604

<oriansj>as it supported 4 Memory channels

<oriansj>it supported registered buffered DIMMs (which mean much higher capacity was possible)

<oriansj>the only difference between bootstrapping rust with 1GB of RAM w/15GB of swap and 16GB of RAM w/o swap is just the speed; not the resulting checksums or if it can be done.

<oriansj>and even if you have a 64GB RAM system, it'll still take 1-2 days to do the full rust toolchain with a E5-1620 0 @ 3.60GHz

<oriansj>There are a boatload of rust bootstrap steps to get to the current version

<Googulator>1-2 days is a lot more acceptable than multiple weeks

<Googulator>does Gentoo Catalyst offer a way to override MAKEOPTS for a single package?

<Googulator>(e.g. build the first Rust on 1 thread, everything else on 4)

<oriansj>well a 10x performance difference between swapping and its all in RAM is actually surprisingly good.

<sam_>Googulator: yes, that can be done via package.env + env

<Googulator>what's that?

<sam_>the way you do what you asked? :)

<sam_> https://wiki.gentoo.org/wiki//etc/portage/package.env

<Googulator>Google proved unhelpful

<Googulator>also, how do I pass this into Catalyst?