Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Samium Gromoff]

>
> > It also has nothing to do with Linux.  Some >motherboard's TAG RAM do not
> > allow for caching more than xMB.
>
> I'm just proposing to update the FAQ to help people >like me
> that thinking to gain speed doubling the system ram >have seen
> a severe performance drop for certain task like >compiling the
> kernel .

 yes, it have nothing to do with linux, but if we can
 improve linux behaviour in the case, i think we should
do it (so in the zone approach people even wouldn`t bother) ...


--


cheers,


   Samium Gromoff

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Samium Gromoff]

> Patch and other info about non cacheable ram here :
> http://www.keryan.org/brad/slram/
>
> ciao,
> luca
    hi guys, the mentioned patch idea is a great one,
  i think, in the light of the situation with only
  512 Mb RAM cached with P2 (as mentioned above)...

  at least detection of uncached RAM is a must.

  should anybody port the patch to 2.4?
(there is still alot of people which use PI`s...),
and using uncached RAM as swap actually will increase
spped, rather than decrease it...

though, there is an other solution: 
allocate the tail as zones marked slow.

comments people?

---


cheers,


   Samium Gromoff

[FAQ?] More ram=less performance (maximum cacheable RAM)

[Luca Montecchiani]

I've recently updated my K6-2 from 128 to 256mbytes (2x128 pc133 dimms)
compiling kernel take now 13 minutes instead of 9 minutes :(

Ram is so cheap and socket7 is far from the death, time for a FAQ?

Here some description from http://9-muses.com/freak/reviews/super7.shtml :
The Level2 Cache determines the board's maximum cacheable RAM. 
Boards equipped with 512k can cache up to 128MB of RAM while
those equipped with 1MB can handle up to 256MB of RAM. If you're using all
of the RAM cacheable by the the L2 cache, performance is enhanced. Once you
go above the maximum cacheable RAM, performance is lost. What this means to
you is the more cache the better. For some users, 64MB or even 128MB of RAM
is enough, but who knows, somewhere down the road, you might want to upgrade
to 256MB. It's nice to know your board can handle the extra memory without
worrying about losing performance.

More technical information can be found here :
http://www.pcguide.com/ref/mbsys/cache/char_Cacheability.htm

Patch and other info about non cacheable ram here :
http://www.keryan.org/brad/slram/

ciao,
luca
-- 
------------------------------------------------------------------
E-mail......: Luca Montecchiani <m.luca@iname.com>
W.W.W.......: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q.......: 17655604
-----------------------=(Linux since 1995)=-----------------------

Non esiste vento favorevole per il marinaio che non sa dove andare
                                                          Seneca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Richard Gooch]

Luca Montecchiani writes:
> I've recently updated my K6-2 from 128 to 256mbytes (2x128 pc133 dimms)
> compiling kernel take now 13 minutes instead of 9 minutes :(
> 
> Ram is so cheap and socket7 is far from the death, time for a FAQ?
> 
> Here some description from http://9-muses.com/freak/reviews/super7.shtml :
> The Level2 Cache determines the board's maximum cacheable RAM. 
> Boards equipped with 512k can cache up to 128MB of RAM while
> those equipped with 1MB can handle up to 256MB of RAM. If you're using all
> of the RAM cacheable by the the L2 cache, performance is enhanced. Once you
> go above the maximum cacheable RAM, performance is lost. What this means to
> you is the more cache the better. For some users, 64MB or even 128MB of RAM
> is enough, but who knows, somewhere down the road, you might want to upgrade
> to 256MB. It's nice to know your board can handle the extra memory without
> worrying about losing performance.
> 
> More technical information can be found here :
> http://www.pcguide.com/ref/mbsys/cache/char_Cacheability.htm
> 
> Patch and other info about non cacheable ram here :
> http://www.keryan.org/brad/slram/

Er, are you sure about this? The problem isn't the size of your cache,
it's the size of your TAG RAM. That's a different beast.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Luca Montecchiani]

Richard Gooch wrote:
> 
> Er, are you sure about this? The problem isn't the size of your cache,
> it's the size of your TAG RAM. That's a different beast.

Yep, this is address in the "More technical information" link ;)
Maybe the first description is not that accurate.

-- 
------------------------------------------------------------------
E-mail......: Luca Montecchiani <m.luca@iname.com>
W.W.W.......: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q.......: 17655604
-----------------------=(Linux since 1995)=-----------------------

Non esiste vento favorevole per il marinaio che non sa dove andare
                                                          Seneca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Robert Love]

On Tue, 2001-08-21 at 15:57, Richard Gooch wrote:
> Er, are you sure about this? The problem isn't the size of your cache,
> it's the size of your TAG RAM. That's a different beast.

It also has nothing to do with Linux.  Some motherboard's TAG RAM do not
allow for caching more than xMB.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Luca Montecchiani]

Robert Love wrote:
> 
> It also has nothing to do with Linux.  Some motherboard's TAG RAM do not
> allow for caching more than xMB.

I'm just proposing to update the FAQ to help people like me 
that thinking to gain speed doubling the system ram have seen
a severe performance drop for certain task like compiling the 
kernel .

Answer : 
It has nothing to do with Linux, maybe your motherboard's TAG Ram
do not allow for caching more than xMB.

ciao,
luca
-- 
------------------------------------------------------------------
E-mail......: Luca Montecchiani <m.luca@iname.com>
W.W.W.......: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q.......: 17655604
-----------------------=(Linux since 1995)=-----------------------

Non esiste vento favorevole per il marinaio che non sa dove andare
                                                          Seneca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Wakko Warner]

> > 
> > It also has nothing to do with Linux.  Some motherboard's TAG RAM do not
> > allow for caching more than xMB.
> 
> I'm just proposing to update the FAQ to help people like me 
> that thinking to gain speed doubling the system ram have seen
> a severe performance drop for certain task like compiling the 
> kernel .
> 
> Answer : 
> It has nothing to do with Linux, maybe your motherboard's TAG Ram
> do not allow for caching more than xMB.

The bios has something to do with that as well.  I have a dual pentium
machine at work that was really slow.  I looked in the bios and it has an
option to cache 64mb or 512mb.  speed up my kernel compiles (2.2.x) by about
12 minutes.  (took 20, after the change, it took about 8)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[idalton]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Wed, Aug 22, 2001 at 07:12:13AM -0400, Wakko Warner wrote:
> > > 
> > > It also has nothing to do with Linux.  Some motherboard's TAG RAM do not
> > > allow for caching more than xMB.
> > 
> > I'm just proposing to update the FAQ to help people like me 
> > that thinking to gain speed doubling the system ram have seen
> > a severe performance drop for certain task like compiling the 
> > kernel .
> > 
> > Answer : 
> > It has nothing to do with Linux, maybe your motherboard's TAG Ram
> > do not allow for caching more than xMB.
> 
> The bios has something to do with that as well.  I have a dual pentium
> machine at work that was really slow.  I looked in the bios and it has an
> option to cache 64mb or 512mb.  speed up my kernel compiles (2.2.x) by about
> 12 minutes.  (took 20, after the change, it took about 8)

Mine has this option, but kernel OOPSes with the option set to 512MB.
It's a TMC TD5TH. I've posted the OOPS before. I can post if anyone
wants to see it.

-- 
Ferret

I will be switching my email addresses from @ferret.dyndns.org to
@mail.aom.geek on or after September 1, 2001, but not until after
Debian's servers include support. 'geek' is an OpenNIC TLD. See
http://www.opennic.unrated.net for details about adding OpenNIC
support to your computer, or ask your provider to add support to
their name servers.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Richard Gooch]

Luca Montecchiani writes:
> Robert Love wrote:
> > 
> > It also has nothing to do with Linux.  Some motherboard's TAG RAM do not
> > allow for caching more than xMB.
> 
> I'm just proposing to update the FAQ to help people like me 
> that thinking to gain speed doubling the system ram have seen
> a severe performance drop for certain task like compiling the 
> kernel .
> 
> Answer : 
> It has nothing to do with Linux, maybe your motherboard's TAG Ram
> do not allow for caching more than xMB.

It's a useful entry, but I don't think it really belongs in the
linux-kernel mailing list FAQ. It belongs in some other
hardware-related document. Better to search for an appropriate one,
and get that updated as needed. I'm happy to add a link to it, though.

I just don't want the LKML FAQ turning into a bloated monster that
tries to answer all questions. The WWW is a *web*, not a central
repository, and works best if we keep it a web. Links Are Good[tm].

While I'm flattered you consider me (or at least the LKML FAQ) the
fount of all knowledge, I really would feel better if others shared in
the burden^Wglory.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Luca Montecchiani]

Richard Gooch wrote:

> It's a useful entry, but I don't think it really belongs in the
> linux-kernel mailing list FAQ. It belongs in some other
> hardware-related document. Better to search for an appropriate one,
> and get that updated as needed. I'm happy to add a link to it, though.
> I just don't want the LKML FAQ turning into a bloated monster that
> tries to answer all questions. The WWW is a *web*, not a central
> repository, and works best if we keep it a web. Links Are Good[tm].
> While I'm flattered you consider me (or at least the LKML FAQ) the
> fount of all knowledge, I really would feel better if others shared in
> the burden^Wglory.

:)

I didn't find any suitable FAQ or HOWTO better than the Hardware-HOWTO
I'll point the whole thread to the author

ciao,
luca
-- 
------------------------------------------------------------------
E-mail......: Luca Montecchiani <m.luca@iname.com>
W.W.W.......: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q.......: 17655604
-----------------------=(Linux since 1995)=-----------------------

Non esiste vento favorevole per il marinaio che non sa dove andare
                                                          Seneca

Re: [FAQ?] More ram=less performance (maximum cacheable RAM)

[Holger Lubitz]

Richard Gooch proclaimed:

> Er, are you sure about this? The problem isn't the size of your cache,
> it's the size of your TAG RAM. That's a different beast.

Cachable memory area is a function of cache size, tag size and cache
mode (wb or wt - first needs dirty tag, second doesn't). With VIA MVP3
boards for example, cachable memory depends on the size of the cache.
Which is why most of the boards with this chipset had 1 MB level 2 cache
(enough for 128 mb with writeback or 256 mb with writethrough), some
even had 2 MB (for twice that).

Holger