On Thu, Nov 5, 2015 at 4:43 PM, Jan Beulich wrote:
On 02.11.15 at 17:29, wrote:
>> * steal_for_cache may now be wrong. I realize that since now ram == 0
>> that all the subsequent "steal_for_cache" expressions will end up as
>> "false" anyway, but leaving invariants in an invalid state is s
>>> On 02.11.15 at 17:29, wrote:
> * steal_for_cache may now be wrong. I realize that since now ram == 0
> that all the subsequent "steal_for_cache" expressions will end up as
> "false" anyway, but leaving invariants in an invalid state is sort of
> asking for trouble.
>
> I'd prefer you just up
On 02/11/15 16:50, Jan Beulich wrote:
On 02.11.15 at 17:29, wrote:
>> On 30/10/15 17:39, Jan Beulich wrote:
>>> Since calling the function isn't cheap, try to avoid the call when we
>>> know up front it won't help; see the code comment for details on those
>>> conditions.
>>>
>>> Signed-off-b
>>> On 02.11.15 at 17:29, wrote:
> On 30/10/15 17:39, Jan Beulich wrote:
>> Since calling the function isn't cheap, try to avoid the call when we
>> know up front it won't help; see the code comment for details on those
>> conditions.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/mm
On 30/10/15 17:39, Jan Beulich wrote:
> Since calling the function isn't cheap, try to avoid the call when we
> know up front it won't help; see the code comment for details on those
> conditions.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.
On 30/10/15 17:39, Jan Beulich wrote:
> Since calling the function isn't cheap, try to avoid the call when we
> know up front it won't help; see the code comment for details on those
> conditions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Since calling the function isn't cheap, try to avoid the call when we
know up front it won't help; see the code comment for details on those
conditions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(str
