Am 31.05.2015 um 21:00 schrieb Thomas Meyer: >> Ping. >> Would be nice to have this patch for the 4.2 merge window. > > I can provide you the current version of the patch, but I'm not sure if > it's ready for inclusion yet.
That's fine. I'll look at it. Just rebase it against Linus' tree or uml-next. https://git.kernel.org/cgit/linux/kernel/git/rw/uml.git/log/?h=linux-next > For example: > - With this patch I see new zombie processes of UML userspace > processes. I'm not sure what's going on here. > - Anton reported some hang he sees with this patch > - A person from cicso is worried about the potential idle CPU usage > after the patch, because of the many timers started, i.e. a host with > hundreds of UMLs. > > Also meanwhile I think is not the correct thing to start a new timer > for each UML userspace process, because the timer will also trigger the > userspace process, even the corresponding process isn't scheduled by > the kernel currently. I think the previous behaviour with the itimer > was okay, because the virtual timer only did execute when the process > was executing which is the correct thing to do for the currently active > task in the UML kernel. > I see two solutions for above problem: cascade the kernel timer into > the current active task; there is actually no need to start a timer in > each userspace process. > Start/stop each timer when a userspace process becomes active resp. > becomes inactive again. > I hope above logic makes some sense at all! What do you think about > this? Hm, we definitely don't want a new timer for each userspace proc. The timer has to work as a regular clock source. But I'll have to read your/Anton's code in detail first. Thanks, //richard ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
