From: Thomas Meyer <thomas@m3y3r.de>
To: user-mode-linux-devel
<user-mode-linux-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
Date: Sun, 19 Oct 2014 14:39:16 +0200 [thread overview]
Message-ID: <1413722356.2991.8.camel@localhost.localdomain> (raw)
Hello,
in UML kernel I get a long cpu using loop in __getnstimeofday()
(kernel/time/timekeeping.c:315) in the call of timespec_add_ns(),
when I left the host kernel suspended to ram for a few hours and resume
again.
this is because it seems like the tk->xtime_sec wasn't updated yet, but
the nsecs were. nsecs can be as high as 8111000111000111000l
the function timespec_add_ns() (include/linux/time.h:266) will call
__iter_div_u64_rem() which has an optimized loop for the case
that the dividend is not much bigger as the divisior.
but this isn't the case for resume from ram on the host kernel.
any ideas how to fix this? is it possible to intercept the resume from
ram and update the timekeeper->xtime_sec somehow?
or can the um arch somehow overwrite timespec_add_ns() to always use
div_u64_rem() instead?
with kind regards
PS: repost on these lists, because nobody did respond to my original
email.
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Meyer <thomas@m3y3r.de>
To: user-mode-linux-devel
<user-mode-linux-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [UM] Long loop in __getnsdayoftime() after resume from ram
Date: Sun, 19 Oct 2014 14:39:16 +0200 [thread overview]
Message-ID: <1413722356.2991.8.camel@localhost.localdomain> (raw)
Hello,
in UML kernel I get a long cpu using loop in __getnstimeofday()
(kernel/time/timekeeping.c:315) in the call of timespec_add_ns(),
when I left the host kernel suspended to ram for a few hours and resume
again.
this is because it seems like the tk->xtime_sec wasn't updated yet, but
the nsecs were. nsecs can be as high as 8111000111000111000l
the function timespec_add_ns() (include/linux/time.h:266) will call
__iter_div_u64_rem() which has an optimized loop for the case
that the dividend is not much bigger as the divisior.
but this isn't the case for resume from ram on the host kernel.
any ideas how to fix this? is it possible to intercept the resume from
ram and update the timekeeper->xtime_sec somehow?
or can the um arch somehow overwrite timespec_add_ns() to always use
div_u64_rem() instead?
with kind regards
PS: repost on these lists, because nobody did respond to my original
email.
next reply other threads:[~2014-10-19 12:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-19 12:39 Thomas Meyer [this message]
2014-10-19 12:39 ` [UM] Long loop in __getnsdayoftime() after resume from ram Thomas Meyer
2014-10-20 8:27 ` [uml-devel] " Richard Weinberger
-- strict thread matches above, loose matches on Subject: below --
2014-10-20 9:51 Thomas Meyer
2014-10-20 9:51 ` Thomas Meyer
2014-10-20 9:56 ` Richard Weinberger
2014-10-20 19:19 ` Thomas Meyer
2015-04-24 19:58 ` Thomas Meyer
2015-04-26 18:32 ` Richard Weinberger
2015-04-26 20:20 ` Richard Weinberger
2015-04-26 20:57 ` Thomas Meyer
2015-04-26 20:57 ` Thomas Meyer
2015-04-26 21:00 ` Richard Weinberger
2015-04-27 5:47 ` Anton Ivanov
2015-04-27 7:23 ` Richard Weinberger
2015-04-27 8:20 ` Anton Ivanov
2015-04-30 16:40 ` Thomas Meyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1413722356.2991.8.camel@localhost.localdomain \
--to=thomas@m3y3r.de \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.