linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Avoiding the highmem mess
@ 2002-08-30 21:54 Scott Kaplan
  2002-08-30 21:59 ` Andrew Morton
  2002-08-30 22:05 ` William Lee Irwin III
  0 siblings, 2 replies; 3+ messages in thread
From: Scott Kaplan @ 2002-08-30 21:54 UTC (permalink / raw)
  To: linux-mm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

As I've mentioned before, I'm trying to do some basic experiments using 
the Linux VM.  Part of doing these experiments will involve reverting the 
kernel to a more ``classic'' kind of structure:  A SEGQ layout where the 
active pages are managed by a CLOCK algorithm, and the inactive pages are 
kept in an LRU queue and are marked ``not present'' so that references to 
them generate a trap.  Critically, I don't aim to produce a kernel that 
will work on non-x86 platforms, let alone NUMA machines or even (at least 
initially) multiprocessor machines.  I want to do some experiments where 
the heart of the matter lies in testing single-processor management.  
(Back to basics!)

SO!  To that end, I'd like to avoid the ZONE_HIGHMEM mess.  It seems oddly 
done, and creates new kinds of contention between pools of pages that I 
don't want polluting my experiments.  (That's not to say that I don't 
think it's a problem worth solving -- it's just not *the* problem that *I*
  want to examine just yet.)

Is there an easy way to avoid ZONE_HIGHMEM?  Is it as easy as avoiding 
machines that have more than 1 GB of physical memory so that only 
ZONE_NORMAL is used?  I'd be happy to just use ZONE_NORMAL (and ZONE_DMA, 
which I'm not all that worried about here) and have my experimental code 
fail to support machines with more than 1 GB.  Later I may want to fix 
that, but I need to start with something simple and comprehensible.

Tips?  Feedback?  Your commentary is greatly appreciated...
Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE9b+mE8eFdWQtoOmgRAtVbAJ45HVBGz6BsDAEaoMQ8sDPSIIUtlACgjNFX
V7wxeT5NNPfS4KDmlqJbsIM=
=B0NR
-----END PGP SIGNATURE-----

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Avoiding the highmem mess
  2002-08-30 21:54 Avoiding the highmem mess Scott Kaplan
@ 2002-08-30 21:59 ` Andrew Morton
  2002-08-30 22:05 ` William Lee Irwin III
  1 sibling, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2002-08-30 21:59 UTC (permalink / raw)
  To: Scott Kaplan; +Cc: linux-mm

Scott Kaplan wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> ...
> Is there an easy way to avoid ZONE_HIGHMEM?  Is it as easy as avoiding
> machines that have more than 1 GB of physical memory so that only
> ZONE_NORMAL is used?

Sure.  Or just disable highmem in kernel config.

But be aware that since 2.5.32, the active/inactive lists are
per-zone.  So you only ever have one type of page on each list.
Probably, this will simplify things.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Avoiding the highmem mess
  2002-08-30 21:54 Avoiding the highmem mess Scott Kaplan
  2002-08-30 21:59 ` Andrew Morton
@ 2002-08-30 22:05 ` William Lee Irwin III
  1 sibling, 0 replies; 3+ messages in thread
From: William Lee Irwin III @ 2002-08-30 22:05 UTC (permalink / raw)
  To: Scott Kaplan; +Cc: linux-mm

On Fri, Aug 30, 2002 at 05:54:09PM -0400, Scott Kaplan wrote:
> SO!  To that end, I'd like to avoid the ZONE_HIGHMEM mess.  It seems oddly 
> done, and creates new kinds of contention between pools of pages that I 
> don't want polluting my experiments.  (That's not to say that I don't 
> think it's a problem worth solving -- it's just not *the* problem that *I*
>  want to examine just yet.)

You'll be fine if you keep physical memory down to less than the kernel
portion of the kernel/user split on 32-bit machines. In principle, if
there were a CONFIG_ISA to #undef and all you had were properly
functioning devices (e.g. no sound cards with only 24 lines wired) and
you could ignore it. OTOH it can be ignored anyway for the most part as
it's a very small pool and not heavily used unless your hardware is bad.

It probably won't be that much of an issue as 2.5.32-bk and/or -mm2 has
separate queues per-zone.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-08-30 22:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-30 21:54 Avoiding the highmem mess Scott Kaplan
2002-08-30 21:59 ` Andrew Morton
2002-08-30 22:05 ` William Lee Irwin III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox