[lkml]   [1996]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: detecting > 64M on x86

On Mon, 23 Dec 1996, Kimon Berlin wrote:
> "Larry M. Augustin" <> wrote:
> > For example, the int 15h ah=c7 get memory map call returns a 42 byte
> > structure that includes how much memory is installed above and below
> > the 16M boundary.
> Ralf Brown's interrupt list says this is a PS/2 function
> "Standard" functions are int 15h, ax=e801h and int 15h, ax=e820h. e820h is
> closest to c7h, it returns a detailed memory map, but it has to be called
> several times, this would bloat setup.S . I think e801h would be enough
> for our purposes,
> Would there be a point in reporting the amount of cachable memory? I don't know
> if any other part of the kernel is designed to have a use for that (i.e. "fast
> pages" and "slow pages").

The memory sub-system isn't designed for fast/slow pages, but having the
information available would be v. useful.
From time-to-time, the question pops up; "I've installed extra
memory, and Linux runs slower!", and answer is (nearly) always due to
pages not being cached (not enough tag-ram, etc). If Linux could
display a warning for this condition, I'd vote for it.
The page allocation routines could also be modified to try and avoid
giving out slow pages, and start paging out when 'fast' pages become low
- a very simple solution, and probably wouldn't work v. well...

> > No, I don't know the difference between local and system memory, and I
> "Local" would be on the motherboard, "system" on another board. Before memory
> modules (SIPPs and SIMMs), when you wanted more memory, you added an ISA (or MCA?)
> card with memory chips on it. Bandwidth was, um, suboptimal.

Would there still be systems out there which have this archiecture? I
somehow doubt it, but watch out for the up coming NUMA machines. Each
'node' will have local memory, but will be able (at a cost) to access
memory on other 'nodes' (a single address space).



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