All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: [PATCH 5 of 5] xen: Avoid allocations causing swap activity on the	resume path
Date: Sat, 31 May 2008 10:50:40 +0100	[thread overview]
Message-ID: <48411F70.5020100@goop.org> (raw)
In-Reply-To: <4840B0C5.4020606@pobox.com>

Jeff Garzik wrote:
> Jeremy Fitzhardinge wrote:
>> From: Ian Campbell <ian.campbell@citrix.com>
>>
>> Avoid allocations causing swap activity on the resume path by allowing
>> such allocations to access the emergency pools otherwise a
>> save/restore/migration of a guest which is low on memory can
>> deadlock.
>>
>> [ linux-2.6.18-xen changesets e8b49cfbdac, fdb998e79aba ]
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>
>> ---
>>  drivers/block/xen-blkfront.c       |    5 +++--
>>  drivers/net/xen-netfront.c         |    4 ++--
>>  drivers/xen/xenbus/xenbus_client.c |    2 +-
>>  drivers/xen/xenbus/xenbus_xs.c     |   10 +++++-----
>>  4 files changed, 11 insertions(+), 10 deletions(-)
>
> IMO I am not qualified enough to ACK or NAK this VM-related patch...

Yeah, I'm not quite sure about which GFP_ flags to use in what 
circumstance.  In this case the potential for deadlock exists because 
this is the code which is reconnecting the virtual devices after a 
resume, which will probably include its storage (either block device, or 
some kind of network storage).  Should GFP_NOFS also be in there?  
Something else?  Does __GFP_HIGH necessarily mean that it won't try to 
do IO to push pages out?

Thanks,
    J


Patch again for reference:

Subject: xen: Avoid allocations causing swap activity on the resume path

From: Ian Campbell <ian.campbell@citrix.com>

Avoid allocations causing swap activity on the resume path by allowing
such allocations to access the emergency pools otherwise a
save/restore/migration of a guest which is low on memory can
deadlock.

[ linux-2.6.18-xen changesets e8b49cfbdac, fdb998e79aba ]

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

---
 drivers/block/xen-blkfront.c       |    5 +++--
 drivers/net/xen-netfront.c         |    4 ++--
 drivers/xen/xenbus/xenbus_client.c |    2 +-
 drivers/xen/xenbus/xenbus_xs.c     |   10 +++++-----
 4 files changed, 11 insertions(+), 10 deletions(-)

===================================================================
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -584,7 +584,7 @@
 
 	info->ring_ref = GRANT_INVALID_REF;
 
-	sring = (struct blkif_sring *)__get_free_page(GFP_KERNEL);
+	sring = (struct blkif_sring *)__get_free_page(GFP_KERNEL | __GFP_HIGH);
 	if (!sring) {
 		xenbus_dev_fatal(dev, -ENOMEM, "allocating shared ring");
 		return -ENOMEM;
@@ -741,7 +741,8 @@
 	int j;
 
 	/* Stage 1: Make a safe copy of the shadow state. */
-	copy = kmalloc(sizeof(info->shadow), GFP_KERNEL);
+	copy = kmalloc(sizeof(info->shadow),
+		       GFP_KERNEL | __GFP_NOFAIL | __GFP_HIGH);
 	if (!copy)
 		return -ENOMEM;
 	memcpy(copy, info->shadow, sizeof(info->shadow));
===================================================================
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1324,7 +1324,7 @@
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_KERNEL);
+	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_KERNEL | __GFP_HIGH);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
@@ -1340,7 +1340,7 @@
 	}
 
 	info->tx_ring_ref = err;
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_KERNEL);
+	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_KERNEL | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
===================================================================
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -117,7 +117,7 @@
 	char *path;
 
 	va_start(ap, pathfmt);
-	path = kvasprintf(GFP_KERNEL, pathfmt, ap);
+	path = kvasprintf(GFP_KERNEL | __GFP_HIGH, pathfmt, ap);
 	va_end(ap);
 
 	if (!path) {
===================================================================
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -283,9 +283,9 @@
 	char *buffer;
 
 	if (strlen(name) == 0)
-		buffer = kasprintf(GFP_KERNEL, "%s", dir);
+		buffer = kasprintf(GFP_KERNEL | __GFP_HIGH, "%s", dir);
 	else
-		buffer = kasprintf(GFP_KERNEL, "%s/%s", dir, name);
+		buffer = kasprintf(GFP_KERNEL | __GFP_HIGH, "%s/%s", dir, name);
 	return (!buffer) ? ERR_PTR(-ENOMEM) : buffer;
 }
 
@@ -297,7 +297,7 @@
 	*num = count_strings(strings, len);
 
 	/* Transfer to one big alloc for easy freeing. */
-	ret = kmalloc(*num * sizeof(char *) + len, GFP_KERNEL);
+	ret = kmalloc(*num * sizeof(char *) + len, GFP_KERNEL | __GFP_HIGH);
 	if (!ret) {
 		kfree(strings);
 		return ERR_PTR(-ENOMEM);
@@ -751,7 +751,7 @@
 	}
 
 
-	msg = kmalloc(sizeof(*msg), GFP_KERNEL);
+	msg = kmalloc(sizeof(*msg), GFP_KERNEL | __GFP_HIGH);
 	if (msg == NULL) {
 		err = -ENOMEM;
 		goto out;
@@ -763,7 +763,7 @@
 		goto out;
 	}
 
-	body = kmalloc(msg->hdr.len + 1, GFP_KERNEL);
+	body = kmalloc(msg->hdr.len + 1, GFP_KERNEL | __GFP_HIGH);
 	if (body == NULL) {
 		kfree(msg);
 		err = -ENOMEM;




  reply	other threads:[~2008-05-31  9:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-31  0:01 [PATCH 0 of 5] xen device driver updates [resend] Jeremy Fitzhardinge
2008-05-31  0:01 ` [PATCH 1 of 5] xen/blkfront: Make sure we don't use bounce buffers, we don't need them Jeremy Fitzhardinge
2008-05-31  1:55   ` Jeff Garzik
2008-05-31  0:01 ` [PATCH 2 of 5] xn/blkfront: Add the CDROM_GET_CAPABILITY ioctl to blkfront Jeremy Fitzhardinge
2008-05-31  1:57   ` Jeff Garzik
2008-05-31  7:08     ` Jeremy Fitzhardinge
2008-05-31  0:01 ` [PATCH 3 of 5] xen/blkfront: Make sure that the device is fully ready before allowing release Jeremy Fitzhardinge
2008-05-31  0:01 ` [PATCH 4 of 5] xen/blkfront: add __exit to module_exit() handlers Jeremy Fitzhardinge
2008-05-31  1:57   ` Jeff Garzik
2008-05-31  0:01 ` [PATCH 5 of 5] xen: Avoid allocations causing swap activity on the resume path Jeremy Fitzhardinge
2008-05-31  1:58   ` Jeff Garzik
2008-05-31  9:50     ` Jeremy Fitzhardinge [this message]
2008-05-31  9:59       ` Andrew Morton
2008-05-31 10:10         ` Jeremy Fitzhardinge
2008-05-31 23:47           ` Andrew Morton
2008-06-01  0:38             ` Jeremy Fitzhardinge
2008-05-31  1:54 ` [PATCH 0 of 5] xen device driver updates [resend] Jeff Garzik
2008-05-31  6:31   ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2008-05-30 23:50 [PATCH 0 of 5] xen device driver updates Jeremy Fitzhardinge
2008-05-30 23:50 ` [PATCH 5 of 5] xen: Avoid allocations causing swap activity on the resume path Jeremy Fitzhardinge

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=48411F70.5020100@goop.org \
    --to=jeremy@goop.org \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=akpm@linux-foundation.org \
    --cc=jens.axboe@oracle.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.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 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.