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

 
 

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

Submitted by:  Thomas Schwinge <tschwinge>
Submitted on:  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
Percent Complete:  0% Assigned to:  None
Open/Closed:  Closed Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project Member
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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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 dependancy from task #6111 => -
    2006-11-16 tschwinge Dependencies- => task #6111 is dependent

    Back to the top


    Powered by Savane 3.3