From: Rafael Aquini <aquini@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>,
Rik van Riel <riel@redhat.com>, Mel Gorman <mel@csn.ul.ie>,
Andi Kleen <andi@firstfloor.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Minchan Kim <minchan@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v10 3/5] virtio_balloon: introduce migration primitives to balloon pages
Date: Tue, 18 Sep 2012 11:07:12 -0300 [thread overview]
Message-ID: <20120918140711.GA1645@optiplex.redhat.com> (raw)
In-Reply-To: <20120917151552.ffbb9293.akpm@linux-foundation.org>
On Mon, Sep 17, 2012 at 03:15:52PM -0700, Andrew Morton wrote:
> > + /* Number of balloon pages isolated from 'pages' list for compaction */
> > + unsigned int num_isolated_pages;
>
> Is it utterly inconceivable that this counter could exceed 4G, ever?
>
> > /* Number of balloon pages we've told the Host we're not using. */
> > unsigned int num_pages;
I've just followed the same unit the driver writers had used to keep track of
how many pages are 'enlisted' to a given balloon device (num_pages). As
compaction can not isolate more pages than what a balloon device possess, yes,
num_isolated_pages won't get bigger than 4G pages.
> > + mutex_lock(&vb->balloon_lock);
> > for (vb->num_pfns = 0; vb->num_pfns < num;
> > vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> > - struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY |
> > - __GFP_NOMEMALLOC | __GFP_NOWARN);
> > + struct page *page = alloc_page(vb_gfp_mask | __GFP_NORETRY |
> > + __GFP_NOWARN | __GFP_NOMEMALLOC);
>
> That looks like an allocation which could easily fail.
>
That's not a big problem. If we fail that allocation and miss the desired
balloon 'inflation' target at this round, the driver will take care of it
later, as it keeps chasing its targets.
> > if (!page) {
> > if (printk_ratelimit())
> > dev_printk(KERN_INFO, &vb->vdev->dev,
>
> Strangely, we suppressed the core page allocator's warning and
> substituted this less useful one.
>
> Also, it would be nice if someone could get that printk_ratelimit() out
> of there, for reasons described at the printk_ratelimit() definition
> site.
>
Despite I agree 100% with you here, (IMHO) that was a change out of the scope
for this patchseries original purposes and so I didn't propose it.
OTOH, I don't mind in introducing the aforementioned surgery by this patch,
if the balloon driver folks are OK with it.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-09-18 14:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 16:38 [PATCH v10 0/5] make balloon pages movable by compaction Rafael Aquini
2012-09-17 16:38 ` [PATCH v10 1/5] mm: introduce a common interface for balloon pages mobility Rafael Aquini
2012-09-17 22:15 ` Andrew Morton
2012-09-18 16:24 ` Rafael Aquini
2012-09-18 22:09 ` Andrew Morton
2012-09-25 1:05 ` Michael S. Tsirkin
2012-09-25 14:00 ` Rafael Aquini
2012-09-24 12:44 ` Peter Zijlstra
2012-09-17 16:38 ` [PATCH v10 2/5] mm: introduce compaction and migration for ballooned pages Rafael Aquini
2012-09-17 16:38 ` [PATCH v10 3/5] virtio_balloon: introduce migration primitives to balloon pages Rafael Aquini
2012-09-17 22:15 ` Andrew Morton
2012-09-18 14:07 ` Rafael Aquini [this message]
2012-09-25 0:40 ` Michael S. Tsirkin
2012-09-25 18:07 ` Rafael Aquini
2012-09-17 16:38 ` [PATCH v10 4/5] mm: introduce putback_movable_pages() Rafael Aquini
2012-09-17 16:38 ` [PATCH v10 5/5] mm: add vm event counters for balloon pages compaction Rafael Aquini
2012-09-17 22:15 ` [PATCH v10 0/5] make balloon pages movable by compaction Andrew Morton
2012-09-17 22:45 ` Rik van Riel
2012-09-18 0:45 ` Rusty Russell
2012-09-25 1:17 ` Michael S. Tsirkin
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=20120918140711.GA1645@optiplex.redhat.com \
--to=aquini@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan@kernel.org \
--cc=mst@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).