On Wed, 2004-11-10 at 13:58 -0800, David Brownell wrote: > On Wednesday 10 November 2004 14:44, Benjamin Herrenschmidt wrote: > > > > > No reason there shouldn't be both. On the other hand, > > > keep in mind that the typical case with selective suspend > > > is going to be that usermode is there, and working just > > > fine ... if you're concerned with shutdown sequences > > > that need userspace to behave, one strategy would be > > > to quiesce more intelligently: shutting down as much > > > as possible *BEFORE* userspace can no longer assist. > > > > It's very difficult to predict. Any block device can be on > > the VM path for example, or a network driver can be in the > > way (NFS) etc... > > Where does "predict" come into it? There are basic > integrity rules to follow, analagous to those which > the driver model already handles. PCI bridges only > suspend after devices on the other side. USB hubs > only suspend after the devices connected to them. > > Shouldn't block devices not "freeze" until after > there's no need to page/swap on them? That is, > until after userspace is refrigerated. We seem > to have a rather ad-hoc model of shutdown ordering; > it's great that we can finally enforce constraints > using bus topology, but that's not all there is. It is useless to refrigerate userspace, just let it block naturally, which is what I do for STR on pmac (STD may still need refrigeration), that doesn't guarantee you won't get more requests though, with things like anticipatory IO scheduler etc... Anyway, your argument doesn't that doesn't change the root of the problem. Any driver relying on userspace help need to be notified when userpsace becomes unavailable, which is basically as soon as we start sending suspend requests to devices. No need to try to do tricks with ordering, i'd pretty much against touching the ordering model at this point anyway. Ben.
