Am Sonntag, den 31.05.2015, 13:15 +0200 schrieb Richard Weinberger: > Am 20.05.2015 um 07:26 schrieb Thomas Meyer: > > > > Am 20.05.2015 12:12 vorm. schrieb Richard Weinberger < > > richard.weinber...@gmail.com>: > > > > > > On Sun, May 17, 2015 at 11:25 AM, Thomas Meyer <tho...@m3y3r.de> > > > wrote: > > > > Switch the UML clocksource from interval timers to posix > > > > interval timers > > > > and move to a monotonic timer. > > > > > > > > This fixes suspend&resume related timer issues and improves > > > > network > > > > performance as TCP state machines are now fed with the correct > > > > time; > > > > also correct QoS and traffic shaping. > > > > > > > > Signed-off-by: Thomas Meyer <tho...@m3y3r.de> > > > > > > What tree is this patch against? > > > It does not clearly apply to Linus' tree. > > > > > > > Hi, > > > > I did tested the patch against 4.1-rc3-something; will update the > > patch against the latest commit! >
Hi, > 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. 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? with kind regards thomas ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
