Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Ulrich Maye » Thu, 05 Mar 1998 04:00:00



I've got a mainboard with the Intel TX chip set, which can just cache
64 MB RAM. Since I've put another 64M in my machine it has noticeable
slowed down. Quite a few people should have encountered this problem
and maybe someone has already managed to configure the upper 64MB as
swap space?
I would greatly appreciate any pointer to a FAQ, a RTFM hint or
instructions on how to do it!
B.t.w I'm using Linux 2.0.33.
Regards and thanks in advance
  Uli
--
-------------------------------------------------------------------

Department of Microelectronic Systems     Phone    +49 6151 16 4039
Darmstadt University of Technology        Fax      +49 6151 16 4936
http://www.microelectronic.e-technik.tu-darmstadt.de/ulim/ulim.html

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Mark Tranchan » Thu, 05 Mar 1998 04:00:00



> I've got a mainboard with the Intel TX chip set, which can just cache
> 64 MB RAM. Since I've put another 64M in my machine it has noticeable
> slowed down. Quite a few people should have encountered this problem
> and maybe someone has already managed to configure the upper 64MB as
> swap space?
> I would greatly appreciate any pointer to a FAQ, a RTFM hint or
> instructions on how to do it!

Look at:

http://www.keryan.ml.org/~keryan/patches/

slram.patch in this directory modifies the kernel to reserve the top <n>
megabytes, and to attach them to /dev/slram. You need to make /dev/slram
first (mknod, block device, 123:0). You can then mkswap or mke2fs this,
or whatever you please.

I have a 486 that only caches 16MB - on upgrading to 28MB, the system
crawled. This patch restores the speed, and making the 12MB /dev/slram a
swap device with higher priority than the HD swap partition drastically
improves system performance under loading.

The other patch interrogates your BIOS to detect the amount of uncached
RAM - I didn't apply this, so I can't comment.


I'd like to do a similar thing under Win95 - anyone know if RAMDRIVE.SYS
makes the ramdrive in the top or the bottom of memory?

Mark.

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by tim » Thu, 05 Mar 1998 04:00:00


Insure the kernel is told the memory on boot line or lilo.conf (hardware
architecture only reports first 64MB by default), then remove ramdisk.
Except for special
cases the memory management subsystem will work better without.


> I've got a mainboard with the Intel TX chip set, which can just cache
> 64 MB RAM. Since I've put another 64M in my machine it has noticeable
> slowed down. Quite a few people should have encountered this problem
> and maybe someone has already managed to configure the upper 64MB as
> swap space?
> I would greatly appreciate any pointer to a FAQ, a RTFM hint or

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Mark Tranchan » Fri, 06 Mar 1998 04:00:00



> Insure the kernel is told the memory on boot line or lilo.conf (hardware
> architecture only reports first 64MB by default), then remove ramdisk.
> Except for special
> cases the memory management subsystem will work better without.

I must be a special case. I went from 16MB => 28MB on my 486, and the
system slowed to a crawl, especially with X. I applied the slram patch
mentioned in my previous posting to create a 12MB ramdisk and used that
as my primary swap partition. The whole system then ran much faster.

Mark.

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Barney Unrea » Mon, 09 Mar 1998 04:00:00


[...]

Quote:> I must be a special case. I went from 16MB => 28MB on my 486, and the
> system slowed to a crawl, especially with X. I applied the slram patch
> mentioned in my previous posting to create a 12MB ramdisk and used that
> as my primary swap partition. The whole system then ran much faster.

If Mark is being serious, Mark has got something horribly messed up.

Using RAM for swap... Hah! That's a good one.

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by mumfo » Tue, 10 Mar 1998 04:00:00





>[...]

>> I must be a special case. I went from 16MB => 28MB on my 486, and the
>> system slowed to a crawl, especially with X. I applied the slram patch
>> mentioned in my previous posting to create a 12MB ramdisk and used that
>> as my primary swap partition. The whole system then ran much faster.

>If Mark is being serious, Mark has got something horribly messed up.

>Using RAM for swap... Hah! That's a good one.

Mark is, I assume, being very serious.  I'm going to be installing the same
slram patch on my gf's 486 (that has 32 megs, running much slower than it
did when it had only 16).

Why is this 'a good one'?  If the memory can't be used for as main memory,
why not use it for swap?  Access to it will be slower than cached memory,
but much faster than the HD.

--

Email to me must have my address in either the To: or Cc: field.  All other
mail will be bounced automatically as spam.
PGPprint = E3 0F DE CC 94 72 D1 1A  2D 2E A9 08 6B A0 CD 82

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Mark Tranchan » Tue, 10 Mar 1998 04:00:00






> >> I must be a special case. I went from 16MB => 28MB on my 486, and the
> >> system slowed to a crawl, especially with X. I applied the slram patch
> >> mentioned in my previous posting to create a 12MB ramdisk and used that
> >> as my primary swap partition. The whole system then ran much faster.

> >If Mark is being serious, Mark has got something horribly messed up.

> >Using RAM for swap... Hah! That's a good one.

> Mark is, I assume, being very serious.  I'm going to be installing the same
> slram patch on my gf's 486 (that has 32 megs, running much slower than it
> did when it had only 16).

> Why is this 'a good one'?  If the memory can't be used for as main memory,
> why not use it for swap?  Access to it will be slower than cached memory,
> but much faster than the HD.

Yes, I am being deadly serious. X, especially, ground to an almost
complete standstill with 28MB of physical RAM available. What was needed
was a mechanism to give the uncached top 12MB of RAM a much lower
priority than the bottom 16MB - and the slram patch achieved it.

Imagine having a section of your HD used as RAM (that is, the kernel
makes no attempt to swap pages to it but uses it exactly as your DRAM).
As soon as an app uses part of that section, it will get accessed many
times (unlike a swapped page, which has been identified as not needed on
a lightly-loaded system), and the system will slow horrifically. My
situation is similar but not quite so extreme.

Believe me, it does make a BIG difference - thanks Brad! Barney - the
only thing horribly messed up is my motherboard design, and I'm not in a
position to buy a new one yet.

Mark.

 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by Barney Unrea » Tue, 10 Mar 1998 04:00:00


[...]

Quote:> Believe me, it does make a BIG difference - thanks Brad! Barney - the
> only thing horribly messed up is my motherboard design, and I'm not in a
> position to buy a new one yet.

I guess I should be sorry for speaking too soon, but
that DID give me a big laugh.  I've never heard of a
MB that didn't cache above 16 MB (64 yes), but even
those people that had no caching above 64MB reported
only a few percent speed difference when using that
memory.  I would expect the extra swapping and
ram-disk overhead would be much slower than some
extra wait cycles.  But then, I guess I expect wrong.
And I'm suprised you can get the system to keep the
ram disk fixed in memory space. Must be a patch to
the nitty-gritty parts.
 
 
 

Q: 128 MB, 64MB cachable -> 64MB RAM disk, swap space?

Post by mumfo » Tue, 10 Mar 1998 04:00:00





>[...]
>> Believe me, it does make a BIG difference - thanks Brad! Barney - the
>> only thing horribly messed up is my motherboard design, and I'm not in a
>> position to buy a new one yet.

>I guess I should be sorry for speaking too soon, but
>that DID give me a big laugh.  I've never heard of a
>MB that didn't cache above 16 MB (64 yes), but even
>those people that had no caching above 64MB reported
>only a few percent speed difference when using that
>memory.  I would expect the extra swapping and
>ram-disk overhead would be much slower than some
>extra wait cycles.  But then, I guess I expect wrong.
>And I'm suprised you can get the system to keep the
>ram disk fixed in memory space. Must be a patch to
>the nitty-gritty parts.

Feel free to try it for yourself to see how much overhead is generated...
You don't *have* to have non-cachable ram to do it, you can do it with
any RAM.

The root problem is that Linux, for some parts, uses memory from _top down_
instead of bottom up, meaning it will start using that uncached ram first
when the system boots.  This means the system will be immediately slow
from boot, and not work its way to being slow.  Also, the factor of slow-
down is several orders of magnitude.  The slowdown on my gf's 486 was much
slower than the computer was when it had less memory and had to swap.

So we have several choices:
1. Use the non-cachable ram as main memory, slowing the system by several
   orders of magnitude.
2. Don't use the non-cachable ram at all, throwing away $$.
3. Use the cachable ram for something where access times better than HD
   access times would be highly desired... ie swap

The overhead you mention is insignificant.  Ram disks wouldn't have even
been created if such an overhead were.

--

Email to me must have my address in either the To: or Cc: field.  All other
mail will be bounced automatically as spam.
PGPprint = E3 0F DE CC 94 72 D1 1A  2D 2E A9 08 6B A0 CD 82

 
 
 

1. Autodetect > 64MB of RAM (was -> Re: 128 MB Linux?)


   : Re-read what Juergen posted.  It's NOT a kernel thing; it's a BIOS
   : thing.  There is no way to query the hardware and get a number bigger
   : than 64MB.  The kernel supports more memory; you just have to tell it
   : about it.  (IE let's say you have 256 Megs of memory.  When the kernel
   : asks the hardware "How much memory do we have?" the hardware responds
   : "64 Megs, sir!"  If you know that the hardware is lying to you, you
   : can override this response.)

Bzzzzt!

You're only correct for machines with very old BIOSes.  Newer machines
(i.e. most machines manufactured after mid/late 1994-ish) have at
least one of 2 newer BIOS interfaces available which can report up
to 4 GB of RAM (the newest interface can report up to 2^64 bytes of RAM,
not that any existing x86 chips can address it :-).

   : If you think that there is a way to find out about more memory,
   : please: code it up, or at least provide references to the hardware
   : calls necessary.  Apparently, nobody's figured out a good way to do
   : this.  

I have!  I have tested this on a machine with 256MB of RAM, and it worked
great!

Take a look at the web pages for my new bootloader GRUB at:

        http://www.uruk.org/grub/

Both a pointer to the FTP area and documentation describing a new booting
standard are available.

I'm going to be sending patches into the main Linux distribution for
Multiboot boot information support sometime in the near future...  but
putting in code which utilizes the new features (multiple module loading
at boot-time, for example) will have to be discussed with some of the
major Linux folks.

   : --

   How does the kernel handle the above 64 Meg memory ? By arranging the MMU
   tables, i think. So, if it CAN address the thing, it should be able to write
   test patterns e.g. at the beginning of each Meg, true ? Now, whith this
   kind of trace we should be able to distinguish true memory from mirrorred
   ore ill addressed junk whereever it happens to be positioned in physical
   address space.

This technique is *NOT* reliable!  It can also wedge your system.

--

Mad Genius wanna-be, CyberMuffin        \__      (finger me for other stats)
Web:  http://www.uruk.org/~erich/     Motto: "I'll live forever or die trying"
  This is my home system, so I'm speaking only for myself, not for Intel.

2. paralellport-problem

3. 128 MB of ram but 64MB displayed

4. GZIP: not found

5. rpc.nisd using >64MB of swap space !!!

6. Easy question : Power connection on ASUS PCI/I-SPG3 MB.

7. How big Swap with 64mb Ram ?

8. Xscreensaver Problems

9. 64Mb RAM enough w/o swap?

10. Sol-2.6 Swap size for Sparc with 64MB RAM?

11. >128 MB RAM stability problems (again)

12. 128 MB RAM reported as 13 MB !!!

13. Linux with > 64MB RAM??