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: <4507F453.1040809@watson.ibm.com>
Date:	Wed, 13 Sep 2006 08:06:43 -0400
From:	Hubertus Franke <frankeh@...son.ibm.com>
To:	schwidefsky@...ibm.com
CC:	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	virtualization@...ts.osdl.org, akpm@...l.org,
	nickpiggin@...oo.com.au, rhim@...gateh.edu
Subject: Re: [patch 1/9] Guest page hinting: unused / free pages.

Martin Schwidefsky wrote:
> On Tue, 2006-09-12 at 21:29 -0400, Rik van Riel wrote:
> 
>>Note that the transition _to_ volatile can also be batched
>>and done somewhat lazily.  For frequently mmaped pages that
>>could end up saving us the transition the other way, too...
> 
> 
> That would be helpful, only how to do it? We need some sort of list or
> array where to store the pages that should be made volatile. The main
> problem that I see is that you have to remove a page that is freed from
> the list/array again, otherwise you would end up with a non page-cache
> page being made volatile. That makes using per-cpu arrays hard since a
> page can be freed on another cpu.
> 


Martin. the point was that pages
which are in the hold/cold lists are technically free.
However we keep them stable.
When the hot/cold list is spilled back to the buddy allocator
we make them volatile in buld (i.e. through the array).
So we only build the array for the duration of the bulk-release
to the buddy allocator (and potentially the other way as well).
Hence there is no "state" to maintain or track for the array.
Pages in the hot/cold lists remain stable.
This would not any of the problems you described as long as we hold
the lock for the hot/cold list during buld-volatile.

I know we did this once. I think we "discarded" the idea
in order to have as many pages volatile as possible.

But this design should be quite easily added and the architecture
can choose whether to be aggressive about this or do it in bulk.

-- Hubertus

-
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