lkml.org 
[lkml]   [1996]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: detecting > 64M on x86

Mark Hemment <markhe@nextd.demon.co.uk> wrote:
> 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...

Unfortunately, there is no BIOS function at this time that will report
the maximum address of cacheable memory. The warning would have to be
chipset-based (i.e. detect which chipset is on the board and display the
warning if it is appropriate); this is probably doable since there are not that
many chipsets floating around anyway.

> 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).

That's a very good reason to implement a slow/fast page system, but I hope
that a NUMA system would not be limited by interrupt 15h to report its
actual memory distribution.

Cheers,
Kimon.
--
Kimon Berlin - Hewlett-Packard Performance Desktop Computing Operation R&D
(BIOS), a spinoff of the Division Formerly Known as GPCD
"You can tune a filesystem, but you can't tune a fish" [HP/UX tunefs(1M)]


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