Messages in this thread |  | | Date | Thu, 18 Oct 2001 16:30:05 -0700 (PDT) | From | Patrick Mochel <> | Subject | Re: [RFC] New Driver Model for 2.5 |
| |
> That's why I prefer more explicit semantics: > > - Prepare sleep: Allocate enough memory to save state. For most > devices, it will be a fixed quantity. In the case of devices that need > per-request allocation, like USB of firewire, just allocate a limited > pool. That means that you will eventually cause serialisation to > happen when not needed and hurt perfs, but nobody will care at this > point ;) > > - Suspend activity: There you lock your IO queues, set your busy flag > or whatever, and wait for any pending IO to be completed. Interrupts > are enabled, scheduling as well (and other CPUs). Each driver is > responsible to properly block a process issuing a request (which should > not be a problem to implement for most of them, a single semaphore > is enough for simple drivers, drivers with IO queues just need to > leave requests in the queues, etc...) > > - Set power state: Here you shut your device down for real. Interrupt > are disabled. Only one CPU is still active (the others can be put in > whatever state your arch allow, like a sleep loop or whatever...).
Ok, so we need another walk before we go to sleep.
But, first a question - does the swap device need to absolutely be the last thing to stop taking requests? Or, can it stop after everything is done allocating memory?
> The actual state save can be in step 2 or 3, we don't really care, > it depends mostly on what is more convenient for the driver writer.
For most devices, it seems it could happen in the first, as well. They should be fine with stopping I/O requests early on. It's only special cases like swap and maybe one or two others that need an extra step, right?
-pat
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |