From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1mN9uc-0004tn-15 for mharc-grub-devel@gnu.org; Mon, 06 Sep 2021 04:23:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mN9uZ-0004m9-D7 for grub-devel@gnu.org; Mon, 06 Sep 2021 04:23:27 -0400 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]:43722) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mN9uX-0003yv-BH for grub-devel@gnu.org; Mon, 06 Sep 2021 04:23:26 -0400 Received: by mail-pg1-x530.google.com with SMTP id r2so6030163pgl.10 for ; Mon, 06 Sep 2021 01:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=8PGEY0gdcOE9yD810WfXgDs+NSisn6wF4qweLofwBk8=; b=n3dgFt0itR3iy9ZPW3MC0TSyUoxgrdVTEmncpYPUTUidvL1kyJR3+LGoYpZA7EPvpz ubXe1I/BlUk2SX42hYFn9aEioyn3qtxz/lqHLZSjfGW5YS7XxRUAjc1L2T8gRUfgfDbJ 5wTGwKeH9c5QRG8xxpjCQMi1ez1JoQMdsi/s8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=8PGEY0gdcOE9yD810WfXgDs+NSisn6wF4qweLofwBk8=; b=kq9JgsNA7FgEWjuKkNOpbDXEj7azKZ9BG0TYPVRnXGQJTGBGMwv/DFWr1Gilnkn6vC 6xrmDCOuRQUNtS11/36uN+WCEJtvnjMmFScHyJKAzJA9UVJvpxqjsTrBKr2pnCTbRA5x kPo+Vje54jZGZjc8PNba50MR9+9IAsMBkGtsLedAh1L6Hu+Ok6CXR2WovbVjRk7d36ey P9z3C7fODNycf78tABlovuppMmRIU24iSqv93VVzZghEVlCK9i8v8oiUJMVmyxKBeupD vF8p4llu5xjpkqxl/QG4xe71nh0MtXOv6QPVwTOEwq4L5GFbkDgr25CIAXW3kwEjexZp DQsw== X-Gm-Message-State: AOAM533bsf3k3wgP9DUb62EYXxH4BxVqco4B7zCLybkbLGF5oClmPUdk OadoqN498fW6y+s8yQiwsVtiQ5lX/JzFsQ== X-Google-Smtp-Source: ABdhPJy26GIL9/xvl5Tp1tIUc3XxZdy9dFuO3S5wXxGgEAKtETKbilhWA61ZsO56u23q9+twO06j2g== X-Received: by 2002:aa7:85d8:0:b0:408:78f4:a5fe with SMTP id z24-20020aa785d8000000b0040878f4a5femr10946715pfn.2.1630916603407; Mon, 06 Sep 2021 01:23:23 -0700 (PDT) Received: from localhost ([2001:4479:e200:df00:dadc:1c0c:1283:1cdb]) by smtp.gmail.com with ESMTPSA id y126sm4025604pfy.88.2021.09.06.01.23.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Sep 2021 01:23:22 -0700 (PDT) From: Daniel Axtens To: Daniel Kiper Cc: Patrick Steinhardt , grub-devel@gnu.org, Leif Lindholm , Stefan Berger Subject: Re: [PATCH v3 2/6] mm: Allow dynamically requesting additional memory regions In-Reply-To: <20210902124012.jg672of3psba4ie3@tomti.i.net-space.pl> References: <3f0ec2a76c1b3aa722efdd540b4d3ecce1789750.1629025332.git.ps@pks.im> <87sfyo5p3b.fsf@dja-thinkpad.axtens.net> <20210902124012.jg672of3psba4ie3@tomti.i.net-space.pl> Date: Mon, 06 Sep 2021 18:23:19 +1000 Message-ID: <87pmtm3yfc.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::530; envelope-from=dja@axtens.net; helo=mail-pg1-x530.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 08:23:27 -0000 >> I think you get away with this on EFI because you use BYTES_TO_PAGES >> and get page-aligned memory, but I think you should probably round up >> to the next power of 2 for smaller allocations or to the next page or >> so for larger allocations. > > I think we could allocate at least e.g. 128 MiB from firmware if there is > not enough memory available in the GRUB mm. This way we would avoid frequent > calls to firmware and could satisfy requests for larger alignments. 128 MiB and 64 MiB cause some tests to fail (cannot allocate memory in echo1 or compression tests because there isn't enough free memory to get a 64MiB chunk). 32 MiB chunk size seems to work and seems fast enough. [It's a bit hard to tell because at some point in time time the powerpc machine stopped shutting down when we got to the end of the tests. oh well.] >> - After fixing that in the ieee1275 code, all_functional_test >> hangs trying to run the cmdline_cat test. I think this is from a slow >> algorithm somewhere - the grub allocator isn't exactly optimised for >> a proliferation of regions. > > Could you try the solution proposed above? Maybe it will solve problem of > frequent additions of memory to the GRUB mm. > >> - I noticed that nearly all the allocations were under 1MB. This seems >> inefficient for a trip out to firmware. So I made the ieee1275 code >> allocate at least max(4MB, (size of allocation rounded up nearest >> 1MB) + 4kB). This makes the tests run with only the usual failures, >> at least on pseries with debug on... still chasing some bugs beyond >> that. > > Yeah, this is similar to what I proposed above. Though I would want to see > larger numbers tested as I said earlier. > >> - The speed impact depends on the allocation size. I'll post something >> on that tomorrow, hopefully, but larger minimum allocations work >> noticably better. >> >> - We only have 4GB max to play with because (at least) powerpc-ieee1275 >> is technically defined to be 32 bit. So I'm a bit nervous about >> further large allocations unless we have a way to release them back >> to _firmware_, not just to grub. > > Ugh... This can be difficult. I am not sure the GRUB mm is smart enough > to release memory regions if they are not used anymore by it. > >> I would think a better overall approach would be to allocate the 1/4 of >> ram when grub starts, and create a whole new interface for large slabs > > I am not very happy with allocating 1/4 of memory at start of the day. > I think allocating larger chunks of memory from firmware should be > enough to make things working as expected. Maybe the per-platform memory chunk allocator just needs to be smart enough to make sure that there is enough memory left over to load a "normal sized" kernel and initrd... although the sizes of distro images keep going up so that's going to be a bit fraught. >> of memory that are directly allocated from, and directly returned to, >> the firmware. I still would really prefer to bypass grub mm completely as described in my other mail. If we are able to give memory back to fw, we can claim 1GB chunks (on SLOF, PFW is going to be another issue) without having to worry about where we put them and if we have enough memory to load a kernel or initrd. It makes it much harder accidentally render your system unbootable. Kind regards, Daniel