Hi Tianyu,
On Tue, Aug 05, 2014 at 10:41:27AM +0800, Lan Tianyu wrote:
> Thanks for your review. We are doing S2RAM optimization.
> We usually use AnalyzeSuspend tool from Brandt, Todd E to observe
> the time consume during S2RAM.(https://github.com/01org/suspendresume.git)
>
> I attached the original result from the tool which showed cpu offline consumes
> more than 100ms. This is due to msleep in the native_cpu_die(). The
> improvement.html shows the test result with the patch. You can't find cpu
> offline at first glance and need to click zoom-in button because the consume
> time of cpu offline is reduced to less than 5ms.
The fact that I can't find it is a good thing, right? :-)
Ok, this looks nice, it actually shows an improvement from cpus going
offline for about 100ish msec and that duration shrinking down to 1.5
msec on average which is a ~100x improv in my book.
And the total S/R time diff looks really good too.
Can people do those measurements outside of your lab? Because if they
can, I could do some on my boxes here too :)
Now, what you could do is run this on a couple of systems, if possible,
write down in the commit message how exactly you did it and add some
relevant numbers to show the speedup. Because this completion thing is
definitely worth pursuing further, provided it doesn't break suspend in
some weird ways.
Btw, the original patches which added the 100ms msleep are:
ef6e525393db ("[PATCH] x86_64: Use msleep in smpboot.c")
aeb8397b6a28 ("[PATCH] i386/smpboot: use msleep() instead of
schedule_timeout()")
and its commit message is, of course, :-( not very telling. WTF does
"task delays as expected" mean? I have to go poke peterz for an idea
what it might've meant...
So do you see what I mean with writing a good, verbose commit message,
explaining the situation?
It needs to explain not what we did but why we did it years from now so
that we know exactly if we have to go touch that code again.
HTH.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
