More ram=less performance (maximum cacheable RAM)
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
Signature · 9 lines
------------------------------------------------------------------ E-mail......: Luca Montecchiani <[email protected]> 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
Quoted 16 lines · 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.
Quoted 5 lines
More technical information can be found here :
http://www.pcguide.com/ref/mbsys/cache/char_Cacheability.htmPatch 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: [email protected] Current: [email protected]
Quoted 2 lines · Richard Gooch
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.
Signature · 3 lines
Robert M. Love rml at ufl.edu rml at tech9.net
Quoted 3 lines · Richard Gooch
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.
Signature · 9 lines
------------------------------------------------------------------ E-mail......: Luca Montecchiani <[email protected]> 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
Quoted 3 lines · Robert Love
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
Signature · 9 lines
------------------------------------------------------------------ E-mail......: Luca Montecchiani <[email protected]> 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
Quoted 5 lines · Luca Montecchiani
Quoted 3 lines · Robert Love
It also has nothing to do with Linux. Some motherboard's TAG RAM do not allow for caching more than xMB.
Quoted 8 lines
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: [email protected] Current: [email protected]
Quoted 4 lines
Quoted 3 lines
It also has nothing to do with Linux. Some motherboard's TAG RAM do not allow for caching more than xMB.
Quoted 8 lines
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)
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 9 lines · Wakko Warner
Quoted 9 lines
Quoted 3 lines
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 .
Quoted 8 lines
Quoted 3 lines
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.
Signature · 8 lines
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.
Quoted 10 lines · Richard Gooch
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
Signature · 9 lines
------------------------------------------------------------------ E-mail......: Luca Montecchiani <[email protected]> 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
Richard Gooch proclaimed:
Quoted 2 lines
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