Messages in this thread |  | | Date | Sat, 3 Feb 2007 01:17:45 +0100 | From | Pavel Machek <> | Subject | Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug |
| |
Hi!
> > Part of what I need to look at. ;-) > > OK. This just might be feasible. That said, there is a lot of code > containing PF_NOFREEZE that I am not familiar with. That said, here > are my thoughts -- this is in addition to the changes to freeze_processes() > and thaw_processes() called out earlier. > > Thoughts?
Looks ok to me.
> o Introduce a mutex to prevent overlapping freezes -- or find > out what the heck prevents them at present!!! (I don't see > anything.)
swsusp is protected by some giant "doing suspend" mutex. Other users may be buggy :-).
> o Replace all the "current->flags |= PF_NOFREEZE" statements with > "exempt_from_freeze(current, int pfe)" or some such. This would > set the flags bit and also store the pfe argument into the pf_exempt > field.
I'd suggest step 0, remove as many PF_NOFREEZE as possible... ok, you seem to be doing that one.
> o init/do_mounts_initrd.c line 57 handle_initrd(). > This looks to be short term anyway, so OK to leave. > But does kernel_execve() clear PF_NOFREEZE? > > But it should be OK to freeze the init process when doing CPU > hotplug ops, right?
That looks bogus. If it is short term, it can as well live _without_ PF_NOFREEZE. Noone should suspend system at that stage, right?
> o kernel/softlockup.c line 88 watchdog(). Well, we wouldn't > want false alarms when freezing for hotplug. Perhaps > temporarily disabling timestamp checking while doing hotplug > would do the trick. But if hotplug takes the time required > to trigger softlockup (seconds!), we are broken anyway. > The fix would be to speed up the freezing process.
Freezing _can_ take seconds. We do sync in between freezing userspace and kernel, for example. We avoid freezing in some difficult situations by waiting for I/O to complete....
> o net/bluetooth/bnep/core.c line 476 bnep_session(). Suspending > to a bluetooth device??? These guys got -hair-!!! I bet this > one can tolerate being frozen for hotplugging CPUs -- though > I could imagine the bluetooth protocol needing some TLC after > such an event. But I don't know enough about bluetooth to do > more than raise the possibility.
Should be fixed. Someone was probably lazy.
> o net/bluetooth/cmtp/core.c line 290 cmtp_session(). Same as > for bnep_session(), at least as far as I can tell. > > o net/bluetooth/hidp/core.c line 476 hidp_session(). Same as > for bnep_session(), AFAICT. > > o net/bluetooth/rfcomm/core.c line 1940 rfcomm_run(). Same as > for bnep_session(), AFAICT.
Someone was definitely lazy :-). Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
|  |