* Re: MM with fragmented memory
[not found] <199810220750.JAA05796@lrcsun15.epfl.ch>
@ 1998-10-22 9:25 ` Rik van Riel
1998-10-22 9:48 ` Werner Almesberger
0 siblings, 1 reply; 3+ messages in thread
From: Rik van Riel @ 1998-10-22 9:25 UTC (permalink / raw
To: Werner Almesberger; +Cc: Linux MM, linux-7110
On Thu, 22 Oct 1998, Werner Almesberger wrote:
> [ Posted to linux-kernel and linux-7110 ]
linux-kernel replaced by linux-mm, since that is where the
MM folks hang around and linux-kernel is busy enough as it
is...
> I'd like to get some opinions on what could be a reasonable memory mapping
> for the Psion S5. The problem with this device is that its physical RAM is
> scattered over a 30 bit address space in little fragments of 512kB,
> aligned to multiples of 1MB. Since it's impossible to fit any useful
> kernel into 512kB, some creative memory layout is necessary.
;)
> I can see two viable approaches:
>
> (1) play linker tricks and insert holes in the kernel such that it skips
> over the gaps in memory. Then map all the memory 1:1 and let
> start_mem and end_mem each have one of the 512kB fragments for
> linear allocation.
> (2) use the MMU to create virtually continuous memory and let the kernel
> manage that in the usual way.
The kernel needs to be aware of the physical mappings, so
it can't virtualize itself...
> The problems I see with (1) are:
> - at least part of the memory layout needs to be known when linking the
> kernel
We already do that on x86 and possibly some other
platforms.
> - allocations from start_mem and end_mem are each limited to a total of
> 512kB
Allocations are limited to 128kB already. There's not much
point in worrying about this and we can keep it into mind
when changing the buddy allocator to something else.
> - need to re-arrange VMALLOC_END, because on ARM-Linux it's 256 MB after
> PAGE_OFFSET, but VMALLOC_START will already have to be about 278 MB
> after that, due to the "exploded" address space. (But that change may
> be harmless.)
> The problems I see with (2) are:
> - virt_to_phys and phys_to_virt now need to perform lookups (in (1)
> they're no-ops). With a few tricks, I can get each of them done in
> about 10 clock cycles, clobbering two registers (out of 16), and
> accessing memory once
> - a little voice in the back of my head saying that something in the
> kernel will certainly trip over a virtual:physical mapping that isn't
> just an offset
I don't know about this -- Stephen, Ingo?
> While I'm attracted by the simplicity of (1), I'm a little worried about
> the limitation for linear allocations. Also, initrd needs a little work
> to function in such a scenario.
>
> The disadvantage of (2) is clearly its complexity. Also, I don't like
> what that little voice is saying ...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: MM with fragmented memory
1998-10-22 9:25 ` MM with fragmented memory Rik van Riel
@ 1998-10-22 9:48 ` Werner Almesberger
1998-10-22 10:26 ` Rik van Riel
0 siblings, 1 reply; 3+ messages in thread
From: Werner Almesberger @ 1998-10-22 9:48 UTC (permalink / raw
To: H.H.vanRiel; +Cc: linux-mm, linux-7110
Rik van Riel wrote:
> linux-kernel replaced by linux-mm, since that is where the
> MM folks hang around and linux-kernel is busy enough as it
> is...
Ah, thanks !
>> - allocations from start_mem and end_mem are each limited to a total of
>> 512kB
>
> Allocations are limited to 128kB already.
Are you sure this limit also applies to linear allocations, i.e.
my_huge_buffer = start_mem;
start_mem += 5*1024*1024;
?
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch /
/_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: MM with fragmented memory
1998-10-22 9:48 ` Werner Almesberger
@ 1998-10-22 10:26 ` Rik van Riel
0 siblings, 0 replies; 3+ messages in thread
From: Rik van Riel @ 1998-10-22 10:26 UTC (permalink / raw
To: Werner Almesberger; +Cc: Linux MM
On Thu, 22 Oct 1998, Werner Almesberger wrote:
> >> - allocations from start_mem and end_mem are each limited to a total of
> >> 512kB
> >
> > Allocations are limited to 128kB already.
>
> Are you sure this limit also applies to linear allocations, i.e.
> my_huge_buffer = start_mem;
> start_mem += 5*1024*1024;
Things like this will have to be done at kernel initialization.
The code is arch-specific and the number of occurances will be
absolutely minimal. Unless, of course, you will want to have
multiple multi-megabyte buffers on your Psion-5 ;)
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1998-10-22 11:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <199810220750.JAA05796@lrcsun15.epfl.ch>
1998-10-22 9:25 ` MM with fragmented memory Rik van Riel
1998-10-22 9:48 ` Werner Almesberger
1998-10-22 10:26 ` Rik van Riel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).