All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Daniel Phillips <phillips@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
Date: Wed, 5 Apr 2006 21:56:36 -0400	[thread overview]
Message-ID: <20060406015636.GE6924@ccure.user-mode-linux.org> (raw)
In-Reply-To: <44343E86.30301@google.com>

On Wed, Apr 05, 2006 at 03:02:46PM -0700, Daniel Phillips wrote:
> > page = alloc_page(GFP_ATOMIC);
> 
> A slightly different objection than Andrew's: this will rapidly eat up
> all the pages available for, e.g., receiving network packets, probably
> not what you want.  How about flags=0?  This will dip a little way into
> reserves but not as far as interrupts or realtime tasks, and will not
> attempt any reclaim.  (Maybe we should have a GFP define for that.)

Yeah, it's a bit non-obvious what 0 means in the twisty little maze of
GFP_ flags.

However, I do want to push the system into reclaim later.  It looks
like the only difference between 0 and GFP_ATOMIC is the use of
emergency pools, which I don't really want to exercise anyway.

> > INIT_LIST_HEAD(&unplugged->list);
> > list_add(&unplugged->list, &unplugged_pages);
> 
> You don't need to initialize the list element you are adding.

This look OK to you?

Index: linux-2.6.16/arch/um/drivers/mconsole_kern.c
===================================================================
--- linux-2.6.16.orig/arch/um/drivers/mconsole_kern.c	2006-04-03 18:05:29.000000000 -0400
+++ linux-2.6.16/arch/um/drivers/mconsole_kern.c	2006-04-05 22:54:17.000000000 -0400
@@ -87,7 +87,11 @@ static irqreturn_t mconsole_interrupt(in
 		if(req.cmd->context == MCONSOLE_INTR)
 			(*req.cmd->handler)(&req);
 		else {
-			new = kmalloc(sizeof(*new), GFP_ATOMIC);
+			/* 0 means don't wait (like GFP_ATOMIC) and
+			 * don't dip into emergency pools (unlike
+			 * GFP_ATOMIC).
+			 */
+			new = kmalloc(sizeof(*new), 0);
 			if(new == NULL)
 				mconsole_reply(&req, "Out of memory", 1, 0);
 			else {
@@ -415,7 +419,6 @@ static int mem_config(char *str)
 
 			unplugged = page_address(page);
 			if(unplug_index == UNPLUGGED_PER_PAGE){
-				INIT_LIST_HEAD(&unplugged->list);
 				list_add(&unplugged->list, &unplugged_pages);
 				unplug_index = 0;
 			}
@@ -655,7 +658,6 @@ static void with_console(struct mc_reque
 	struct mconsole_entry entry;
 	unsigned long flags;
 
-	INIT_LIST_HEAD(&entry.list);
 	entry.request = *req;
 	list_add(&entry.list, &clients);
 	spin_lock_irqsave(&console_lock, flags);

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Dike <jdike@addtoit.com>
To: Daniel Phillips <phillips@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
Date: Wed, 5 Apr 2006 21:56:36 -0400	[thread overview]
Message-ID: <20060406015636.GE6924@ccure.user-mode-linux.org> (raw)
In-Reply-To: <44343E86.30301@google.com>

On Wed, Apr 05, 2006 at 03:02:46PM -0700, Daniel Phillips wrote:
> > page = alloc_page(GFP_ATOMIC);
> 
> A slightly different objection than Andrew's: this will rapidly eat up
> all the pages available for, e.g., receiving network packets, probably
> not what you want.  How about flags=0?  This will dip a little way into
> reserves but not as far as interrupts or realtime tasks, and will not
> attempt any reclaim.  (Maybe we should have a GFP define for that.)

Yeah, it's a bit non-obvious what 0 means in the twisty little maze of
GFP_ flags.

However, I do want to push the system into reclaim later.  It looks
like the only difference between 0 and GFP_ATOMIC is the use of
emergency pools, which I don't really want to exercise anyway.

> > INIT_LIST_HEAD(&unplugged->list);
> > list_add(&unplugged->list, &unplugged_pages);
> 
> You don't need to initialize the list element you are adding.

This look OK to you?

Index: linux-2.6.16/arch/um/drivers/mconsole_kern.c
===================================================================
--- linux-2.6.16.orig/arch/um/drivers/mconsole_kern.c	2006-04-03 18:05:29.000000000 -0400
+++ linux-2.6.16/arch/um/drivers/mconsole_kern.c	2006-04-05 22:54:17.000000000 -0400
@@ -87,7 +87,11 @@ static irqreturn_t mconsole_interrupt(in
 		if(req.cmd->context == MCONSOLE_INTR)
 			(*req.cmd->handler)(&req);
 		else {
-			new = kmalloc(sizeof(*new), GFP_ATOMIC);
+			/* 0 means don't wait (like GFP_ATOMIC) and
+			 * don't dip into emergency pools (unlike
+			 * GFP_ATOMIC).
+			 */
+			new = kmalloc(sizeof(*new), 0);
 			if(new == NULL)
 				mconsole_reply(&req, "Out of memory", 1, 0);
 			else {
@@ -415,7 +419,6 @@ static int mem_config(char *str)
 
 			unplugged = page_address(page);
 			if(unplug_index == UNPLUGGED_PER_PAGE){
-				INIT_LIST_HEAD(&unplugged->list);
 				list_add(&unplugged->list, &unplugged_pages);
 				unplug_index = 0;
 			}
@@ -655,7 +658,6 @@ static void with_console(struct mc_reque
 	struct mconsole_entry entry;
 	unsigned long flags;
 
-	INIT_LIST_HEAD(&entry.list);
 	entry.request = *req;
 	list_add(&entry.list, &clients);
 	spin_lock_irqsave(&console_lock, flags);

				Jeff

  reply	other threads:[~2006-04-06  2:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24 18:14 [uml-devel] [PATCH 12/16] UML - Memory hotplug Jeff Dike
2006-03-24 18:14 ` Jeff Dike
2006-03-24 22:45 ` [uml-devel] " Andrew Morton
2006-03-24 22:45   ` Andrew Morton
2006-03-24 23:58   ` [uml-devel] " Blaisorblade
2006-03-24 23:58     ` Blaisorblade
2006-03-25  1:19     ` Jeff Dike
2006-03-25  1:19       ` Jeff Dike
2006-03-25  1:05   ` Jeff Dike
2006-03-25  1:05     ` Jeff Dike
2006-04-05 22:02     ` [uml-devel] " Daniel Phillips
2006-04-05 22:02       ` Daniel Phillips
2006-04-06  1:56       ` Jeff Dike [this message]
2006-04-06  1:56         ` [uml-devel] " Jeff Dike
2006-04-06  3:32         ` Andrew Morton
2006-04-06  3:32           ` Andrew Morton
2006-04-06  3:33           ` Andrew Morton
2006-04-06  3:33             ` Andrew Morton
2006-04-06  3:42         ` Daniel Phillips
2006-04-06  3:42           ` Daniel Phillips
2006-03-25 19:26   ` Jan Engelhardt
2006-03-25 19:26     ` Jan Engelhardt
2006-03-25 20:08     ` [uml-devel] " Jeff Dike
2006-03-25 20:08       ` Jeff Dike

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=20060406015636.GE6924@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@google.com \
    --cc=user-mode-linux-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.