taskThe GNU Hurd - Tasks: task #5782, Handling of large memory equipment...

 
 

task #5782: Handling of large memory equipment by GNU Mach

Submitter:  Thomas Schwinge <tschwinge>
Submitted:  Sun 06 Aug 2006 09:43:11 PM UTC
   
 
Category:  GNU Mach Should Start On:  Sat 05 Aug 2006 10:00:00 PM UTC
Should be Finished on:  Sat 05 Aug 2006 10:00:00 PM UTC Priority:  * 3 - Low
Status:  Cancelled Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Closed Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 03 Feb 2013 07:50:18 PM UTC, comment #2: 

We can now change the 3/1 limit to 2/2. A 64bit port is also underway, which should help, rather than doing on-demand mapping.

Samuel Thibault <sthibaul>
Group administrator
Sun 06 Aug 2006 09:58:31 PM UTC, comment #1: 

Well, this doesn't really have to do with the patch. The patch just makes it clear that with its current memory layout, GNU can't handle more than 1GB.

Using another memory layout is possible: Linux people have done it with their "HIGHMEM" option. But this is a horrible bug-prone mess which now reveals to be useless since we will all have 64bits-capable systems sooner or later, won't we? ;)

So I'd say "why bother?". If people want more than 1GB, they should just buy 64. At the time we are really able to fill 1GB with KDE/Gnome/OOo/whatever, I guess we will all have 64.

Note: this is not exactly 1GB, yes. Again, we might do like Linux: shift the 1GB/3GB limit between kernel and user so that the kernel can really map 1GB of memory.

Anonymous
Sun 06 Aug 2006 09:43:11 PM UTC, original submission:  

Starting with the application of the patch from bug #7118, GNU Mach's usage of the machine's memory equipment is currently forced to be somewhere below 1 GiB, to make GNU Mach work at all on systems with such enlarged RAM installations.  This is -- of course -- not optimal.  See the calculation of and with `kernel_virtual_end' and `morevm' in i386/intel/pmap.c and `phys_last_addr' in i386/i386at/model_dep.c.

Thomas Schwinge <tschwinge>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tschwinge (Updated the item)
  • -email is unavailable- added by sthibaul (Posted a comment)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-06 tschwinge StatusNone Cancelled
        Open/ClosedOpen Closed
    2006-11-22 tschwinge DependenciesRemoved dependency from task #6111 -
    2006-11-16 tschwinge Dependencies- task #6111 is dependent

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code