All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
Date: Fri, 24 Mar 2006 20:05:24 -0500	[thread overview]
Message-ID: <20060325010524.GA8117@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060324144535.37b3daf7.akpm@osdl.org>

On Fri, Mar 24, 2006 at 02:45:35PM -0800, Andrew Morton wrote:
> The `= 0;' causes this to consume space in vmlinux's .data.  If we put it
> in bss and let crt0.o take care of zeroing it, we save a little disk space.

Yup.

> > +			page = alloc_page(GFP_ATOMIC);
> 
> That's potentially quite a few atomically-allocated pages.  I guess UML is
> more resistant to oom than normal kernels (?) but it'd be nice to be able to
> run page reclaim here.

This is the big question with this patch.  How incestuous do I want to
get with the VM system in order to get it to free up pages?  For now,
I decided to be fairly hands-off, allocate as many pages as I can get,
and return the total number to the host.  The host, if it wasn't happy
with the results, can wait a bit while the UML notices that it is
really low on memory and frees some up, and then hit up the UML for
the remainder.

> > +	char buf[sizeof("18446744073709551615\0")];
> 
> rofl.  We really ought to have a #define for "this architecture's maximum
> length of an asciified int/long/s32/s64".  Generally people do
> guess-and-giggle-plus-20%, or they just get it wrong.

I can write one up.  I did some quick grepping, and there are a good
number of constant over-estimates, plus some which might be in danger
with an large number of devices, plus one (kallsyms.c) which actually
does some sane-looking approximate math to get a reasonable number (which
is then doubled).

>  * NOTE: Currently, only shmfs/tmpfs is supported for this operation.
>  * Other filesystems return -ENOSYS.
> 
> Are you expecting that this memory is backed by tmpfs?

Yes, but there should be some checking of this beforehand.

Drop this version for now, and I'll send a new one to cover these
problems plus the one that BlaisorBlade pointed out.

				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: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [PATCH 12/16] UML - Memory hotplug
Date: Fri, 24 Mar 2006 20:05:24 -0500	[thread overview]
Message-ID: <20060325010524.GA8117@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060324144535.37b3daf7.akpm@osdl.org>

On Fri, Mar 24, 2006 at 02:45:35PM -0800, Andrew Morton wrote:
> The `= 0;' causes this to consume space in vmlinux's .data.  If we put it
> in bss and let crt0.o take care of zeroing it, we save a little disk space.

Yup.

> > +			page = alloc_page(GFP_ATOMIC);
> 
> That's potentially quite a few atomically-allocated pages.  I guess UML is
> more resistant to oom than normal kernels (?) but it'd be nice to be able to
> run page reclaim here.

This is the big question with this patch.  How incestuous do I want to
get with the VM system in order to get it to free up pages?  For now,
I decided to be fairly hands-off, allocate as many pages as I can get,
and return the total number to the host.  The host, if it wasn't happy
with the results, can wait a bit while the UML notices that it is
really low on memory and frees some up, and then hit up the UML for
the remainder.

> > +	char buf[sizeof("18446744073709551615\0")];
> 
> rofl.  We really ought to have a #define for "this architecture's maximum
> length of an asciified int/long/s32/s64".  Generally people do
> guess-and-giggle-plus-20%, or they just get it wrong.

I can write one up.  I did some quick grepping, and there are a good
number of constant over-estimates, plus some which might be in danger
with an large number of devices, plus one (kallsyms.c) which actually
does some sane-looking approximate math to get a reasonable number (which
is then doubled).

>  * NOTE: Currently, only shmfs/tmpfs is supported for this operation.
>  * Other filesystems return -ENOSYS.
> 
> Are you expecting that this memory is backed by tmpfs?

Yes, but there should be some checking of this beforehand.

Drop this version for now, and I'll send a new one to cover these
problems plus the one that BlaisorBlade pointed out.

				Jeff

  parent reply	other threads:[~2006-03-25  1:04 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 [this message]
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       ` [uml-devel] " Jeff Dike
2006-04-06  1:56         ` 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=20060325010524.GA8117@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.