All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Thomas <bthomas@virtualiron.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] - return error when appropriate from increase_memory_reservation
Date: Thu, 20 Apr 2006 15:41:58 -0400	[thread overview]
Message-ID: <4447E406.3030204@virtualiron.com> (raw)
In-Reply-To: <a5d2e90866045115abc4cce9241b4f33@cl.cam.ac.uk>

You're right - I was fixing this too quickly. The issue I was
encountering is that xc_domain_memory_increase_reservation
may return 0(success) when no pages have been reserved.  Put
this in a loop and you get, well, interesting results.

There are several possible solutions for this, all done at
that level.  However, it isn't clear to me at this moment
what the best and most correct solution would be. So, I'm
going to put this off for now and continue to use a different
approach.

Thanks,
-b

Keir Fraser wrote:
> 
> On 20 Apr 2006, at 19:04, Ben Thomas wrote:
> 
>> This patch fixes a case in increasing a memory reservation where you
>> do not get the pages nor do you get an error.  While an argument might
>> be made that checking the page count independently is workable, it
>> does seem reasonable to have the operation return a failure in the
>> cases where it doesn't do what was asked. Right now, it mostly returns
>> the correct status.  This patch just adds another instance of this.
> 
> 
> No. In cases where it fails it does not undo its partial work. The 
> current return lets the caller know how much work was done so that 
> appropriate action can be taken. The callers need fixing -- there aren't 
> that many. Only increase_reservation or populate_physmap can fail, 
> unless the caller is buggy, so they are the only ones that really need 
> fixing. The others should probably BUG_ON() or assert or print an error 
> in the caller though.
> 
>> And, while-I-was-there, I've been generating linker maps for qemu in
>> my own builds. It's harmless, until you need it and then it's valuable.
>> Tweak the Makefile to create the map.
> 
> 
> I'll take that as a separate patch.
> 
>  Thanks,
>  Keir
> 


-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851

      reply	other threads:[~2006-04-20 19:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20 18:04 [PATCH] - return error when appropriate from increase_memory_reservation Ben Thomas
2006-04-20 18:52 ` Keir Fraser
2006-04-20 19:41   ` Ben Thomas [this message]

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=4447E406.3030204@virtualiron.com \
    --to=bthomas@virtualiron.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /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.