On Fri, 25 Apr 2008, Ingo Molnar wrote:That really isn't true. This isn't done just once. It's done many thousands of times. I agree that it has to be robust, but if we want to make suspend/resume be instantaneous (and we do), performance does actually matter. Yes, this is probably much less of a problem than waiting for devices, and no, I haven't timed it, but if I counted right, we'll literally be going almost ten thousand of these calls over a suspend/resume cycle. That's not "rarely used". Linus --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Andrew Morton | 2.6.23-rc6-mm1 |
| Eric Paris | [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
