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: <1157130150.21733.70.camel@localhost>
Date:	Fri, 01 Sep 2006 19:02:30 +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:29 -0700, Dave Hansen wrote:
> > 3) The page-has-a-writable-mapping (PG_writable) bit is set when the
> > first writable pte for a page is established. The page needs to have a
> > different state if a writable pte exists compared to a read-only page.
> > The alternative without the page bit would be to do the state change
> > every time a writable pte is established or to search all ptes of a
> > given page. Both have performance implications.  
> 
> What are the performance implications?  Do they completely erase any
> performance gains that these patches might have given in the first
> place?  Has there been any evaluation of these other two alternatives?
> As I understand it, carrying out this performance analysis would be very
> difficult for most of the kernel community to perform.

It seemed obvious to me that anything else than checking a bit is way to
expensive. I never implemented nor measured any of the alternatives. The
alternative to do the state change every time a writable pte is
established can be implemented without too much trouble. Perhaps I will
give it a try next week.

> Keeping a nice count of the number of writable PTEs sounds like
> something that might be generally useful.  Could we split
> page->_mapcount to keep track of r/o and r/w ptes separately?  Or,
> perhaps a single bit in it can be utilized to replace PG_writable,
> instead.

Yes, that would be really useful for the writable ptes. But I have the
feeling that the actual implementation of it will be tricky.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ