lkml.org 
[lkml]   [1996]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Memory in Kernel space
Date
From

"Leonard N. Zubkoff" writes:
> From: Paul Gortmaker <gpg109@rsphy6.anu.edu.au>
> Date: Fri, 31 May 1996 17:02:55 +1000 (EST)
>
> Wow. If you need that much, then you are better off not letting the
> kernel have it in the first place. Simply boot with "mem=7m" and
> you can meddle with the upper 25MB as you see fit. The kernel won't
> touch it, and you don't need to futz about with kmalloc().
>
>I don't think it's quite that simple. I tried this once, and if I recall
>correctly, the memory above the mem= value won't be mapped at all and the
>kernel will fault trying to access it. There probably is a way, but it's more
>complicated than this.

The memory will get mapped in if you vremap() it in, won't it?
vremap is supposed to take an offset greater than the high end
of memory and a length and return a virtual address with all
that area mapped in.

Try doing:
pointer_to_upper_25mb = vremap(1024*1024*7, 25*1024*1024);
or something like that. Look at mm/vmalloc.c for the definition
of vmalloc. Then pointer_to_upper_25mb holds a pointer to
virtual addresses in the top GB of memory which is mapped to
the addresses in question.

Naturally, for production code, you want this to be configurable,
but that's not difficult to do.

Is there something I'm missing here?

Please tell me if this works; I can put it in the KHG as a
useful workaround for things that need huge amounts of
consecutive memory.

michaelkjohnson


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.074 / U:8.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site