Re: [PATCH 12/16] UML - Memory hotplug

[Jeff Dike <jdike@addtoit.com>]

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