public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: <hannes@cmpxchg.org>, "Ingo Molnar" <mingo@elte.hu>
Cc: <linux-kernel@vger.kernel.org>
Subject: alloc_bootmem_low() mis-uses
Date: Fri, 13 Mar 2009 14:53:02 +0000	[thread overview]
Message-ID: <49BA815E.76E4.0078.0@novell.com> (raw)

As you are being listed as the authors of mm/bootmem.c, I'd like to raise
the following issues in the hope that you can shed some additional light on
the original intentions of that code.

>From looking at all the callers of this and similar functions I'm getting the
impression that the majority of them are actually mis-uses: These functions
should really only be used when there is a need for getting an address
below ARCH_LOW_ADDRESS_LIMIT, but they should in particular not be
used just because the caller wants to make sure he doesn't get any
highmem range back (which is because highmem never enters the bootmem
allocator in the first place). Or am I missing something here?

A second aspect is that there is no attempt to preserve memory below
ARCH_LOW_ADDRESS_LIMIT for those few callers that really need to
get such memory (swiotlb, ACPI sleep) - 'normal' bootmem allocations
honor MAX_DMA_ADDRESS, but not ARCH_LOW_ADDRESS_LIMIT. This
apparently can, on systems with very much memory, lead to earlier
huge allocations (e.g. alloc_large_system_hash() and
alloc_node_mem_map()) exhausting almost all of the memory below that
boundary. Not avoiding that area may also result in unnecessary
pressure on later GFP_DMA32 allocations.

Wouldn't it therefore be reasonable to
- eliminate all the bogus callers of alloc_bootmem_low() & Co,
- change ___alloc_bootmem_nopanic() to use a three (or even multi) stage
  search, based on the fact that the goal argument isn't something that
  must be strictly adhered to anyway, and
- change alloc_bootmem_core() to start allocating from the top rather
  than the bottom?

Thanks, Jan


                 reply	other threads:[~2009-03-13 15:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=49BA815E.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox