On 03/19/2013 04:22:07 PM, Johannes Berg wrote:

On Tue, 2013-03-19 at 16:10 -0500, Scott Wood wrote:
=20

quoted

quoted

I was going to say I have no idea, but looking at it again ... =20

this is

quoted

quoted

in the *resume* code, not the suspend code as I'd assumed, and on
resume
I guess I felt it was safer to not assume it didn't change, since =20

it

quoted

quoted

could be a slightly different kernel that loaded and restored the
hibernation image?

Wouldn't that be doomed for other reasons?

=20
Most likely, yeah.
=20

quoted

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

=20
Good question, but would they be running? You have to have everything
built in that you need to load the image? Or maybe not, with the
userspace image restoration that became possible at some point...

Is that all that's being restored in this step, or would we be loading =20
all modules that were loaded before suspend (as they're normally not =20
swappable)?  I'm not too familiar with what gets saved where.

quoted

It's not a displacement flush (i.e. you don't do a separate load =20

pass

quoted

first) -- it just flushes lines if they happen to be present, and
leaves alone anything outside that range.  Given that you just =20

finished

quoted

copying a bunch of data, most likely what's in the cache is the last
bit of data you copied.

=20
Oops, good point.
=20
Maybe there's a way to completely flush the (i)cache? :-)

There is, but it's platform-dependent, and not pleasant on our chips =20
(need a displacement flush for L1, and sometimes errata are involved =20
for L2).

-Scott=