On Sun 26 Mar 2023 at 19:13:20 +0200, Anders Magnusson wrote: > Den 2023-03-26 kl. 18:29, skrev Rhialto: > > On Sun 26 Mar 2023 at 16:28:52 +0200, Anders Magnusson wrote: > > > Please look at the patch: > > [ correctly limits the total size ] > > > > > After everything is calculated I check if kvmsize gets larger than 1G, and > > > in that case truncates it to 1G. > > > I haven't changed the calculations. > > But that's my point. For smaller memory sizes, it likely calculates a > > bigger page table size than needed (by counting things double) (and thus > > wastes memory on the page table). > > > > That is of course a different bug, but now that we're looking at > > this area of code we might well think about how it should be. > That is the problem - there is no usable way to know how much virtual memory > is needed in advance since most data structures is allocated on demand. > Doubling avail_end seemed to be a working way to match the memory that might > be allocated (by using empirical tests, some 20 years ago). I have a pessimistic feeling that the kernel allocator will limit itself to nkmempages as calculated, and not think about the extra memory size that's added to it; at least that is how uvm_map_prepare() seems to be used in uvm_km_bootstrap(). So unless it can grow, any extra virtual pages won't be used. Or I'm wildly guessing very wrong of course, since I am hardly an expert in this part of the code :-) > There maybe is a better way to do this, feel free to work on it :-) I can just read enough of this code that it smells wrong to me, but I don't know how it is supposed to be ;-) > -- Ragge -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto
Attachment:
signature.asc
Description: PGP signature