[13:01] <m15k> Hi guys. Should ufw dhcp-pd work out of the box?
[13:06] <Sircle> https://pastebin.mozilla.org/9078945
[13:06] <Sircle> Is there anything wrong with this syntax. I am trying to allow one ip and block all but its blocking all ips (including the one I whitelisted) https://pastebin.mozilla.org/9078945
[14:43] <zul> coreycb:  ping neutron-vpnaas could use a rebuild in the cloud-archive https://pastebin.com/hL9b25q7
[15:06] <jamespage> zul: neutron-vpn-agent has gone
[15:10] <jamespage> as in the vpn bits run as an extension to the neutron-l3-agent in queens
[15:27] <zul> argh...ok
[21:41] <sdeziel> I have a bunch of QEMU VMs with small RAM allocations (256M or less) but the VM's kernel seems to be missing ~20M leading to only ~236M visible/usable. Any way to find where the rest is gone?
[21:42] <sdeziel> "journalctl -kocat | grep Memory" gives me: Memory: 227764K/261624K available (8530K kernel code, 1309K rwdata, 3992K rodata, 1508K init, 1316K bss, 33860K reserved, 0K cma-reserved)
[21:43] <sdeziel> 261624K is pretty close to what the VM is given 262144K
[21:43] <nacc> sdeziel: says 33M reserved?
[21:44] <sdeziel> nacc: yeah, any way to influence this? Or learn what it's for?
[21:44] <sdeziel> is that a safety stash to be used only when under memory pressure?
[21:44] <nacc> sdeziel: can you `cat /proc/meminfo` to a pastebin?
[21:45] <sdeziel> https://paste.ubuntu.com/p/7mPvT9hf96/
[21:45] <nacc> lol which give sa different number :)
[21:45] <sdeziel> my 236M visible from "free -m" is exactly the MemTotal
[21:46] <nacc> sdeziel: you've got about 20 M of reclaimable slab memory
[21:46] <sdeziel> I know that long ago there was a thing like reserved memory for DMA/ISA
[21:46] <nacc> which is relatively high for a small footprint system
[21:46] <sdeziel> SReclaimable >
[21:47] <nacc> sdeziel: yeah
[21:47] <nacc> i believe you can force that to reclaim by drop_caches
[21:47]  * sdeziel wonders how to reclaim
[21:48] <nacc> sdeziel: try echo 3 > /proc/sys/vm/drop_caches
[21:48] <sdeziel> brought it down to ~8M
[21:48] <sdeziel> the that is poking at something that's not MemTotal AFAICT
[21:48] <nacc> sdeziel: err, duh, you're right
[21:49] <nacc> sdeziel: can you pastebin the full dmesg?
[21:49] <sdeziel> I experimented with an even smaller VM (192M assigned) and was also missing 20M
[21:50] <sdeziel> https://paste.ubuntu.com/p/8ysM3kGX4t/
[21:52] <nacc> sdeziel: i used to know this really well, but i'm a few years rusty now :/
[21:52] <nacc> sdeziel: trying to remember
[21:54] <sdeziel> nacc: hehe, nothing urgent, I'm only trying to reclaim as much as I can to keep my super old VM server from running out of RAM
[21:54] <nacc> sdeziel: iirc, that memory is kernel pages
[21:55] <nacc> sdeziel: and i think that means you used something like 20M of bootmem or so
[21:55] <nacc> whcih can't be freed normally
[21:55] <sdeziel> I wonder what that means: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[21:55] <sdeziel> hmm, bootmem you say
[21:56] <nacc> sdeziel: that's my recollection, the kernel's bootsrap memory
[21:56] <nacc> sdeziel: that's referring to the e820 map in firmware
[21:56] <nacc> your bios tells the kerenl physically what addresses are allowed, etc
[21:57] <sdeziel> OK
[21:57] <TJ-> sdeziel: the kernel protects the first 64KB of memory from use, and actively scans it for corruption (to detect writes to the NULL page
[21:57] <sdeziel> TJ-: vm.mmap_min_addr right ?
[21:58] <sdeziel> TJ-: I tried shrinking it from 65536 -> 2048 and didn't get anything back
[21:58] <sdeziel> I also booted the linux-image-kvm flavor and got much less RAM taken away from me
[21:59] <TJ-> sdeziel: I don't think so, no, the e820 0-0xFFF is reserving the first 4096 byte page for safety
[21:59] <sdeziel> the problem with the kvm flavor is that it's a wildly different beast
[22:01] <nacc> TJ-: oh you're right, i didn't read which message that was properly
[22:02] <sdeziel> TJ-: OK but if it's for safety purposes, shouldn't the kernel see it (and count it in MemTotal)?
[22:05] <sdeziel> "dmesg | grep BIOS-e820" shows 5 ranges as reserved
[22:06] <nacc> sdeziel: right those are bios reserved, and then the kernel removes a bit more
[22:06] <TJ-> sdeziel: no, because those reserved areas are often 'ROM' - e.g. system BIOS and option ROMs, or PCI device mappings
[22:08] <sdeziel> hmm
[22:08] <TJ-> sdeziel: see e.g. "sudo less /proc/iomem"
[22:10] <sdeziel> "000c0000-000c0dff : Video ROM" => the VM only has a serial console
[22:11] <TJ-> sdeziel: but the VM seabios presumably has a default e820 reservation for a standard VGA framebuffer
[22:14] <sdeziel> TJ-: I don't know that area at all but I would think that such mapping wouldn't remove RAM visible for the kernel
[22:19] <TJ-> In the dmesg Memory line you referenced, the 'reserved' is:  (physpages - totalram_pages - totalcma_pages) << (PAGE_SHIFT - 10),
[22:24] <sdeziel> not sure where totalram_pages comes from though
[22:26] <sdeziel> I'm just lacking too much basic knowledge I guess I should start reading https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
[22:28] <sdeziel> huh, this ^ not related at all
[22:31] <TJ-> no, that's about device-tree bindings
[22:33] <sdeziel> TJ-: yeah, I noticed. While I look around for documentation of the e820 memory mapping hints, do you know how I could minimize the amount of reserved memory?
[22:33] <sdeziel> TJ-: something to tweak with QEMU/seabios?
[22:34] <TJ-> sdeziel: did you pastebin the entire dmesg ?
[22:35] <sdeziel> TJ-: https://paste.ubuntu.com/p/8ysM3kGX4t/
[22:36] <TJ-> sdeziel: and what's in /proc/iomem
[22:36] <sdeziel> qemu as invoked by libvirt: https://paste.ubuntu.com/p/FX8RtzN5wK/
[22:37] <sdeziel> TJ-: iomem: https://paste.ubuntu.com/p/NV45Nk9bjm/
[23:02] <hehehe> hehe
[23:02] <hehehe> any new exciting news?
[23:03] <dpb1> yes
[23:04] <hehehe> cool
[23:52] <sdeziel> TJ-: nacc: thanks for the useful information
[23:53] <nacc> sdeziel: yw, hopefully you were able to figure stuff out?
[23:53] <sdeziel> nacc: not yet but I have some pointers now at least