Messages in this thread | | | Subject | Re: [lkcd-devel] Re: What's left over. | From | (Eric W. Biederman) | Date | 09 Nov 2002 20:23:50 -0700 |
| |
Werner Almesberger <wa@almesberger.net> writes:
> Eric W. Biederman wrote: > > So my gut impression at least says an interface that ignores where > > the image wants to live just adds complexity in other places, > > Linus' alloc_kernel_pages function would actually be able to handle > this, provided that the "validity callback" checks if the allocated > page happens to be in one of the destination areas. > > I'm not so sure if this implementation is really that much more > compact than your current conflict resolution, though. Also, it may > be hairy in scenarios where you actually expect to fill more than > 50% of system memory. (But your concerns about a 128MB limit scare > me, too. I realize that people have taken initrds to extremes I > never quite imagined, but that still looks a little excessive :-)
I have not heard of more than about 90MB. One of the things I would not be surprised to see in the next couple of years as memory gets cheaper is diskless systems that don't even bother doing NFS root and just put everything in an initrd. But that is not the main concern.
Since there are more polite ways of allocating memory already implemented. Sucking up a 16MB hunk of some ones vmalloc space is quite rude. Currently the limit is pretty much 50% of system memory or 1GB whichever is less because the code must be loaded into user space first, and I don't touch high memory. Although I guess if it was mmaped read only the limit may be higher.
I don't expect to come to close to using all of system memory except on limited memory systems. But it is always nice to be polite.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |