Hi. On Saturday 21 July 2007 08:43:20 [email protected] wrote: > On Fri, 20 Jul 2007, Alan Stern wrote: > > > On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote: > > > >>>> when doing a suspend-to-ram you get to a point where you just don't use > >>>> any userspace. > >> > >>> What do you mean? How can you prevent user tasks from running? That's > >>> basically what the freezer does, and the whole point of this approach > >>> is to eliminate the freezer. Right? > >> > >> Presumably no tasks at all would be scheduled. > > > > How would you prevent tasks from being scheduled? How would you > > prevent drivers from deadlocking because in order to put their device > > in a low-power state they need to acquire a lock which is held by a > > user task? > > you give up on the suspend becouse you have no way of getting the user > task to give up the lock. > > however, kernel locks should not be held by user tasks, user tasks are not > expected to behave in rational ways, allowing them to compete with kernel > tasks for locks is a sure way to get a deadlock or indefinate stall. > > what locks are accessed this way? Any userspace process can do a syscall. In the process of the syscall, it can take kernel locks, and it can schedule (eg, while seeking to take a second lock). Regards, Nigel
Attachment:
pgpShX1Ncas0E.pgp
Description: PGP signature
- References:
- Prev by Date: Re: where is the code for read system call?
- Next by Date: Re: [RFC, Announce] Unified x86 architecture, arch/x86
- Previous by thread: Re: [linux-pm] Re: Hibernation considerations
- Next by thread: Re: [linux-pm] Re: Hibernation considerations
- Index(es):