All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Daniel Axtens <dja@axtens.net>, Leif Lindholm <leif@nuviainc.com>,
	Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [PATCH v3 0/6] Runtime allocation of memory regions
Date: Mon, 30 Aug 2021 20:05:29 +0200	[thread overview]
Message-ID: <YS0d6ZqcYDvJCIB3@tanuki> (raw)
In-Reply-To: <20210830174907.mhvzxxinxeugdhca@tomti.i.net-space.pl>

[-- Attachment #1: Type: text/plain, Size: 3752 bytes --]

On Mon, Aug 30, 2021 at 07:49:07PM +0200, Daniel Kiper wrote:
> On Fri, Aug 27, 2021 at 01:39:05PM +1000, Daniel Axtens wrote:
> > Daniel Kiper <dkiper@net-space.pl> writes:
> >
> > > Hey,
> > >
> > > Adding Daniel Axtens...
> > >
> > > On Sun, Aug 15, 2021 at 01:09:06PM +0200, Patrick Steinhardt wrote:
> > >> Hi,
> > >>
> > >> this is the third version of my patch set to implement runtime
> > >> allocation of additional memory regions.
> > >>
> > >> Changes compared to v2:
> > >>
> > >>     - A new preparatory patch was added to remove unused code which
> > >>       unloaded modules on OOM.
> > >>
> > >>     - Patch 2/4 has been split up into two patches: one to drop the
> > >>       logic where we request a quarter of available memory and then
> > >>       put bounds to it, and one to split apart request of additional
> > >>       regions and initialization of the EFI MM system.
> > >>
> > >>     - Flags are now `unsigned int` instead of `unsigned`.
> > >>
> > >>     - `add_memory_regions ()` now gets all flags instead of only a
> > >>       single flag `consecutive`.
> > >>
> > >>     - Flags are now defines and not an enum anymore.
> > >>
> > >>     - The callback function is now called `grub_mm_add_region_func_t`
> > >>       instead of `grub_mm_region_func_t`. Flags and its variable have
> > >>       been renamed accordingly.
> > >>
> > >> Patrick
> > >>
> > >> Patrick Steinhardt (6):
> > >>   mm: Drop unused unloading of modules on OOM
> > >>   mm: Allow dynamically requesting additional memory regions
> > >>   efi: mm: Always request a fixed number of pages on init
> > >>   efi: mm: Extract function to add memory regions
> > >>   efi: mm: Pass up errors from `add_memory_regions ()`
> > >>   efi: mm: Implement runtime addition of pages
> > >>
> > >>  grub-core/kern/dl.c     | 20 ----------
> > >>  grub-core/kern/efi/mm.c | 83 +++++++++++++++++++----------------------
> > >>  grub-core/kern/mm.c     | 12 +++---
> > >>  include/grub/dl.h       |  1 -
> > >>  include/grub/mm.h       | 16 ++++++++
> > >>  5 files changed, 61 insertions(+), 71 deletions(-)
> > >
> > > Patrick, I went quickly through this patch series and in general it
> > > LGTM. There are some minor issues but we can fix them later. Thank
> > > you for doing this work.
> > >
> > > Stefan and/or Daniel Axtens, may I ask you to test these patches with
> > > your use case? If it works for you please repost this patch series with
> > > your changes added. Then I will merge it after final review.
> >
> > Sure, I'll have a look.
> >
> > My initial thoughts are:
> >
> >  - with the CAS support patch. We would still need that, and would want
> >    to do that call early as possible because it will cause the partition
> >    to be rebooted.
> >
> >  - We have to be careful where we ask for memory because the kernel
> >    assumes that there will be some free memory below a particular address.
> >
> >   - I'd also want to verify what the performance impact would be - not
> >     just on powerpc-ieee1275 but also on efi - of going out to
> >     OpenFirmware/UEFI for each new zone...
> 
> Good point! I was thinking about performance at some point too. Sadly
> I forgot to say something about that... Patrick, did you compare
> performance before and after you patch series? If the impact is
> significant maybe we should not change initial allocation strategy
> and add a function to allocate more memory during runtime only...
> 
> > I'll test this early next week and report back.
> 
> Cool! Thanks a lot!
> 
> Daniel

The question is how to measure performance. Are there any benchmarks
that result in somewhat reproducible results?

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-08-30 18:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-15 11:09 [PATCH v3 0/6] Runtime allocation of memory regions Patrick Steinhardt
2021-08-15 11:09 ` [PATCH v3 1/6] mm: Drop unused unloading of modules on OOM Patrick Steinhardt
2021-08-15 11:09 ` [PATCH v3 2/6] mm: Allow dynamically requesting additional memory regions Patrick Steinhardt
2021-09-01 14:48   ` Daniel Axtens
2021-09-02 12:40     ` Daniel Kiper
2021-09-03 12:23       ` Daniel Axtens
2021-09-12 11:13         ` Patrick Steinhardt
2021-09-06  8:23       ` Daniel Axtens
2021-09-10  0:03         ` Daniel Kiper
2021-09-27 14:18           ` Daniel Axtens
2021-08-15 11:09 ` [PATCH v3 3/6] efi: mm: Always request a fixed number of pages on init Patrick Steinhardt
2021-08-15 11:09 ` [PATCH v3 4/6] efi: mm: Extract function to add memory regions Patrick Steinhardt
2021-08-15 11:09 ` [PATCH v3 5/6] efi: mm: Pass up errors from `add_memory_regions ()` Patrick Steinhardt
2021-08-15 11:09 ` [PATCH v3 6/6] efi: mm: Implement runtime addition of pages Patrick Steinhardt
2021-08-26 15:12 ` [PATCH v3 0/6] Runtime allocation of memory regions Daniel Kiper
2021-08-27  3:39   ` Daniel Axtens
2021-08-30 17:49     ` Daniel Kiper
2021-08-30 18:05       ` Patrick Steinhardt [this message]
2021-09-01  5:50         ` Daniel Axtens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YS0d6ZqcYDvJCIB3@tanuki \
    --to=ps@pks.im \
    --cc=dja@axtens.net \
    --cc=grub-devel@gnu.org \
    --cc=leif@nuviainc.com \
    --cc=stefanb@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.