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

[Anton Ivanov <anton.ivanov@kot-begemot.co.uk>]

On 31/05/15 20:00, Thomas Meyer wrote:
> 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.

Agree.

> For example:
> - With this patch I see new zombie processes of UML userspace
> processes. I'm not sure what's going on here.

+1

> - Anton reported some hang he sees with this patch

I did not have a chance to work on it last week, will try to find some
time this week. 

> - 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.
This is less then the old CPU usage - checking time and rearming
nanosleeps and itimers is expensive.

>
> 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?

Cascading the kernel timer looks like the correct solution.

A.

>
> 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
>


------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel