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 MachShould Start On: Sat 05 Aug 2006 10:00:00 PM UTC
Should be Finished on: Sat 05 Aug 2006 10:00:00 PM UTCPriority: 3 - Low
Status: CancelledPrivacy: Public
Percent Complete: 0%Assigned to: None
Open/Closed: ClosedPlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 06 Oct 2013 03:13:48 PM UTCtschwingeStatusNone=>Cancelled
      Open/ClosedOpen=>Closed
    Wed 22 Nov 2006 12:04:58 AM UTCtschwingeDependenciesRemoved dependancy from task #6111=>-
    Thu 16 Nov 2006 12:06:39 PM UTCtschwingeDependencies-=>task #6111 is dependent

    Back to the top


    Powered by Savane 3.1-cleanup