linux-kernel - Re: [patch 3/9] Guest page hinting: volatile page cache.

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]

Message-Id: <1157127943.21733.52.camel@localhost>
Date:	Fri, 01 Sep 2006 18:25:43 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Dave Hansen <haveblue@...ibm.com>
Cc:	Andy Whitcroft <apw@...dowen.org>, linux-kernel@...r.kernel.org,
	virtualization@...ts.osdl.org, akpm@...l.org,
	nickpiggin@...oo.com.au, frankeh@...son.ibm.com
Subject: Re: [patch 3/9] Guest page hinting: volatile page cache.

On Fri, 2006-09-01 at 09:18 -0700, Dave Hansen wrote:
> > 1) The page-is-discarded (PG_discarded) bit is set for pages that have
> > been recognized as removed by the host. The page needs to be removed
> > from the page cache while there are still page references floating
> > around. To prevent multiple removals from the page cache the discarded
> > bit is needed.
> 
> OK, so the page has data in it, and is in the page cache.  The
> hypervisor kills the page, gives the notification to the kernel that the
> page has gone away, and the kernel marks PG_discarded.  There still
> might be active references to the page.

No, the hypervisor does not give the notification immediatly. A discard
fault is delivered to the guest if it tries to access a page that has
been removed by the host. That is the fundamental difference between a
memory ballooner and the guest page hinting.

> So, is the problem trying to communicate with the reference holders that
> the page is no longer valid?  How is this fundamentally different from
> page truncating?

Truncating is similar but the reaction is different. A truncated page is
gone and will not be recreated. A discarded page can be reloaded.

> > 2) The page-state-change (PG_state_change) bit is required to prevent
> > that an make_stable "overtakes" a make_volatile. In order to make a page
> > volatile a number of conditions are check. After this is done the state
> > change will be done. The critical section is the code that performs the
> > checks up to the instruction that does the state change. No make_stable
> > may be done in between. The granularity is per page, to use a global
> > lock like a spinlock would severly limit the scalability for large smp
> > systems.
> 
> How about doing it in the NUMA node?  Or the mem_section?  Or, even a
> bit in the mem_map[] for the area guarding the 'struct page' itself?
> Even a hashed table of locks based on the page address.  You just need
> something that allows _some_ level of concurrency.  You certainly never
> have a number of CPUs which is anywhere close to the number of 'struct
> page's in the system.

NUMA node is not granular enough, mem_section is probably doable. I do
not understand the part about the bit in the mem_map[] area, a bit in
the page->flags is exactly that, isn't it?

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.


-
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/