From: Anthony Liguori <aliguori@us.ibm.com>
To: John L Griffin <jlg@us.ibm.com>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: Calculating real cpu usage of Xen domains correctly!
Date: Thu, 24 Feb 2005 14:43:24 -0600 [thread overview]
Message-ID: <421E3C6C.2070507@us.ibm.com> (raw)
In-Reply-To: <OF59DA85E6.DADAE5C6-ON85256FB2.0049AD80-85256FB2.004C9A88@us.ibm.com>
Hi John,
John L Griffin wrote:
>My quick perusal of the current xeno-unstable code suggests that this
>SCHED_OP call is a null call. The SCHED_OP macro attempts to call the
>"do_block" function pointed to in the "struct scheduler sched_bvt_def"
>array, but this function pointer is never initialized, so it just does a
>NOP.
>
>
Yes. I agree.
>It appears that what your patch does is limit when cpu_time gets updated,
>such that the time only gets updated when the exec_domain is in the
>BLOCKED state:
>
>
No. Currently, cpu_time will always get updated for the prev domain
when __enter_scheduler() is called. My patch modifies that behavior the
behavior so that it only gets updated if prev->blocked is false or if
prev->blocked is true but there are events pending for the domain. The
last part may not be right.
> if ( test_bit(EDF_BLOCKED, &prev->ed_flags) )
> prev->cpu_time += now - prev->lastschd;
> }
>
>
Sorry, this is my fault, my mail client badly munged the patch when I
copy-pasted it. Let me show you the code:
if ( test_bit(EDF_BLOCKED, &prev->ed_flags) )
{
/* This check is needed to avoid a race condition. */
if ( event_pending(prev) )
clear_bit(EDF_BLOCKED, &prev->ed_flags);
else
SCHED_OP(do_block, prev);
}
prev->cpu_time += now - prev->lastschd;
Was changed to:
if ( test_bit(EDF_BLOCKED, &prev->ed_flags) )
{
/* This check is needed to avoid a race condition. */
if ( event_pending(prev) )
{
clear_bit(EDF_BLOCKED, &prev->ed_flags);
prev->cpu_time += now - prev->lastschd;
} else
SCHED_OP(do_block, prev);
} else {
prev->cpu_time += now - prev->lastschd;
}
It's not pretty at all. I'm not sure if the update after clear_bit() is
necessary either.
>What this seems to be saying (in regard to your patch working) is that the
>cpu_time is updated when the domain relinquishes the CPU by block()ing,
>but cpu_time doesn't get updated if it relinquishes the CPU by yield()ing.
>
>
No, it's the opposite. Sorry, I think the whitespace munging made the
patch confusing.
>I wonder why this works. Is anyone familiar with block() vs yield(), that
>could lend some insight into what's going on?
>
>
I'm quite confident this is the cause of the problem. I'm just not sure
about that one cpu_time update.
Regards,
Anthony Liguori
>JLG
>
>
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-02-24 20:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-24 2:37 Calculating real cpu usage of Xen domains correctly! Ian Pratt
2005-02-24 3:10 ` Anthony Liguori
2005-02-24 13:56 ` John L Griffin
2005-02-24 20:43 ` Anthony Liguori [this message]
2005-02-24 21:46 ` John L Griffin
2005-02-24 22:02 ` Keir Fraser
2005-02-24 23:01 ` Anthony Liguori
2005-02-25 3:53 ` John L Griffin
2005-02-25 10:31 ` Stephan Diestelhorst
2005-02-25 10:38 ` Stephan Diestelhorst
-- strict thread matches above, loose matches on Subject: below --
2005-02-24 0:48 Ian Pratt
2005-02-24 1:02 ` Anthony Liguori
2005-02-24 2:10 ` Andrew Theurer
2005-02-25 2:25 ` Matt Ayres
2005-02-25 2:38 ` Anthony Liguori
2005-02-25 16:44 ` Rob Gardner
2005-02-25 17:10 ` Anthony Liguori
2005-02-23 23:29 Jerone Young
2005-02-23 23:44 ` Anthony Liguori
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=421E3C6C.2070507@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=jlg@us.ibm.com \
--cc=xen-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.