linux-kernel - Re: [Feature] x86_64 page tracking for Stratus servers

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: <44FE9690.7060008@yahoo.com.au>
Date:	Wed, 06 Sep 2006 19:36:16 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andi Kleen <ak@...e.de>
CC:	Kimball Murray <kimball.murray@...il.com>,
	linux-kernel@...r.kernel.org, akpm@...eo.com
Subject: Re: [Feature] x86_64 page tracking for Stratus servers

Andi Kleen wrote:

>>Silly question, why can't you do all this from stop_machine_run context (or
>>your SMI) that doesn't have to worry about other CPUs dirtying memory?
>>
>
>Because that would be too slow for continuous mirroring.
>
>You can't go through 10+GB of virtual memory (or more with shared 
>memory because the scan has to be virtual) in an interrupt.
>
>The only sane way is to do it continuously.
>

Presumably it is not continuous but there are checkpoints, and in the
worst case, enforcement of a checkpoint will require an SMI.

But OK, heuristically I'm sure it is much quicker to already have most
memory saved. I guess this is a requirement otherwise they would have
done it the obvious way... but my question is just about what exact
requirement does this satisfy that a stop_machine would not.

>
>>[*] Though if it gets included, it would not stop me lamenting the
>>proliferation of complexities to support *tiny* obscure userbases. Can
>>we wait until your hardware is smart enough to snoop the cc? :)
>>
>
>
>My guess is that if we had a generic memory mirror subsystem other people would
>find uses for it too. e.g. a lot of systems support spare DIMMs these days and mirroring
>some memory to it seems like a smart idea. That means normally the hardware
>does it, but perhaps some stuff can be done better by doing it in software.
>
>Or it is also a bit similar to the algorithms Xen uses for live migration.
>If that was implemented on the kernel level something like this might 
>be useful too. I think OpenVZ has some kind of migration support, but it's
>currently not live.
>

Yep, I'm not saying it couldn't be useful.

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/