Re: [uml-devel] [PATCH] um: Switch clocksource to hrtimers

[Thomas Meyer <thomas@m3y3r.de>]

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.weinberger@gmail.com>:
> > > 
> > > On Sun, May 17, 2015 at 11:25 AM, Thomas Meyer <thomas@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 <thomas@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