On 03/19/2013 03:55:34 PM, Johannes Berg wrote:

On Mon, 2013-03-18 at 17:12 -0500, Scott Wood wrote:
=20

quoted

Could you elaborate on why book3s flushes the way it does?  What's
special about the first 32 MiB?  If it's to cover kernel code, why
would that be changing from what's already there?

=20
I was going to say I have no idea, but looking at it again ... this is
in the *resume* code, not the suspend code as I'd assumed, and on =20
resume
I guess I felt it was safer to not assume it didn't change, since it
could be a slightly different kernel that loaded and restored the
hibernation image?

Wouldn't that be doomed for other reasons?

I wonder about kernel modules, though flushing 32 MiB wouldn't be =20
adequate there.

It should be the same one, so I guess it should be
exactly the same code, but I guess I wanted to make sure there wasn't
anything weird there. As for why it'd be 32 MiB? No idea. Although =20
that
really ought to flush all your possible caches anyway, I guess.

It's not a displacement flush (i.e. you don't do a separate load pass =20
first) -- it just flushes lines if they happen to be present, and =20
leaves alone anything outside that range.  Given that you just finished =20
copying a bunch of data, most likely what's in the cache is the last =20
bit of data you copied.

-Scott=