"struct page" and allocating high memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  inspired by rene's latest postings, i went back to review my memory
management and i'm confused by a comment i found in one of the MM
header files.

  it's well-known that *all* of the physical memory on a system is
represented by an array of "struct page" structures, which i can
condense to:

  struct page {
	...
	void *virtual;
	...
  }

so, as i read it, if a physical page is currently mapped into the
kernel address space, that member will contain its virtual address.
OTOH, if it *isn't* mapped, that pointer will contain NULL.  so far,
so good?

  also, memory allocation in the "normal" zone of the 32-bit x86
address space should always return contiguous physical memory, but
allocation from the "highmem" zone promises to return only *virtually*
contiguous memory.  again, all of that's fairly straightforward.  but
here's where the glitch shows up, in this comment from
include/linux/gfp.h:

/*
 * There is only one page-allocator function, and two main namespaces to
 * it. The alloc_page*() variants return 'struct page *' and as such
 * can allocate highmem pages, the *get*page*() variants return
 * virtual kernel addresses to the allocated page(s).
 */

  now, if i allocate a chunk of space from the normal zone and i get
back a valid address after the allocation succeeds, it seems to me
that i can represent that space with either the returned virtual
address *or* the address of the "page" structure, right?  and that's
because, as long as the space allocated is physically contiguous, then
a single "struct page *" value will represent the first struct and the
rest of the consecutive ones after that that define that space.

  however, if i allocate space from high memory (896M and up using,
say, vmalloc()), what i'll get back if that call succeeds is the
resulting virtual address ***but*** , since there's no guarantee that
those pages are contiguous, each page could be represented by some
arbitrary "page" structure, no?

  so how to explain this part of the comment from above?

  "The alloc_page*() variants return 'struct page *' and as such can
allocate highmem pages, ..."

  huh?  if you're allocating "highmem" pages, i don't see how you can
represent the allocated space with a single struct page pointer
(unless, of course, it's a single page, but that's not what's being
addressed here).

  so what does that comment mean?  it seems to be exactly backwards
from what i'm used to believing.

rday
--



========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux