linux-kernel - Re: [linux-pm] [PATCH] hibernation should work ok with memory hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 05 Nov 2008 20:10:05 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Matt Tolentino <matthew.e.tolentino@...el.com>,
	linux-pm@...ts.osdl.org, Dave Hansen <haveblue@...ibm.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, pavel@...e.cz,
	Mel Gorman <mel@...net.ie>, Andy Whitcroft <apw@...dowen.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [PATCH] hibernation should work ok with
	memory	hotplug

Hi.

On Mon, 2008-11-03 at 23:53 -0800, Dave Hansen wrote:
> On Tue, 2008-11-04 at 18:30 +1100, Nigel Cunningham wrote:
> > One other question, if I may. Would you please explain (or point me to
> > an explanation) of PHYS_PFN_OFFSET/ARCH_PFN_OFFSET? I've been dealing
> > occasionally with people wanting to have hibernation on arm, and I don't
> > really get the concept or the implementation (particularly when it comes
> > to trying to do the sort of iterating over zones and pfns that was being
> > discussed in previous messages in this thread.
> 
> First of all, I think PHYS_PFN_OFFSET is truly an arch-dependent
> construct.  It only appears in arm an avr32.  I'll tell you only how
> ARCH_PFN_OFFSET looks to me.  My guess is that those two arches need to
> reconcile themselves and start using ARCH_PFN_OFFSET instead.
> 
> In the old days, we only had memory that started at physical address 0x0
> and went up to some larger address.  We allocated a mem_map[] of 'struct
> pages' in one big chunk, one for each address.  mem_map[0] was for
> physical address 0x0 and mem_map[1] was for 0x1000, mem_map[2] was for
> 0x2000 and so on...
> 
> If a machine didn't have a physical address 0x0, we allocated mem_map[]
> for it anyway and just wasted that entry.  What ARCH_PFN_OFFSET does is
> let us bias the mem_map[] structure so that mem_map[0] does not
> represent 0x0.
> 
> If ARCH_PFN_OFFSET is 1, then mem_map[0] actually represents the
> physical address 0x1000.  If it is 2, then mem_map[0] represents
> physical addr 0x2000.  ARCH_PFN_OFFSET means that the first physical
> address on the machine is at ARCH_PFN_OFFSET*PAGE_SIZE.  We bias all
> lookups into the mem_map[] so that we don't waste space in it.  There
> will never be a zone_start_pfn lower than ARCH_PFN_OFFSET, for instance.
> 
> What does that mean for walking zones?  Nothing.  It only has meaning
> for how we allocate and do lookups into the mem_map[].  But, since
> everyone uses pfn_to_page() and friends, you don't ever see this.
> 
> I'm curious why you think you need to be concerned with it.

Sorry for the delay in replying.

It's because I'm looking at old patches for arm support for TuxOnIce and
because of the way TuxOnIce records what pages need attention:

My method of recording what needs doing is different to Rafael's. I use
per zone bitmaps (constructed out of order 0 allocations) and therefore
look at zone_start_pfn in calculating what bit within the zone needs to
be set/cleared/tested.

In your example above, zone_start_pfn will be 1, won't it? If that's the
case, I shouldn't need to subtract ARCH_PFN_OFFSET to get the right
index within the zone and avoid the same wastage that ARCH_PFN_OFFSET
avoids with mem_map.

Nigel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/