On 03/19/2013 04:22:07 PM, Johannes Berg wrote:
On Tue, 2013-03-19 at 16:10 -0500, Scott Wood wrote:
> > 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
> > 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?
Most likely, yeah.
> I wonder about kernel modules, though flushing 32 MiB wouldn't be
> adequate there.
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
all modules that were loaded before suspend (as they're normally not
swappable)? I'm not too familiar with what gets saved where.
> It's not a displacement flush (i.e. you don't do a separate load
pass
> first) -- it just flushes lines if they happen to be present, and
> leaves alone anything outside that range. Given that you just
finished
> copying a bunch of data, most likely what's in the cache is the last
> bit of data you copied.
Oops, good point.
Maybe there's a way to completely flush the (i)cache? :-)
There is, but it's platform-dependent, and not pleasant on our chips
(need a displacement flush for L1, and sometimes errata are involved
for L2).
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
