[Gllug] Wrong "mem=XXXm" makes kernel *slow*?

[Christian Smith]

On Tue, 22 Feb 2005, Mike Brodbelt wrote:

>On Mon, 2005-02-21 at 21:35 +0000, John Winters wrote:
>
>> Reducing the memory further (to 992m - i.e. 32m reserved) got the system
>> to boot normally.  Now, I can understand why not reserving enough causes
>> the system to crash, but I can't imagine why it would cause the system
>> to run very slowly.  Anyone know why?
>
>Typically this happens because the motherboard chipset doesn't properly
>cache all the installable memory on the board. Ther kernel loads at the
>top of memory, so if that area is in uncached memory it slows everything
>down straight away. The slram kernel driver is provided to allow the use
>of this memory as fast disk, though in 2.6 I think the suggestion is to
>use phram (which I've never looked at). Of course motherboard docs
>rarely make a point of mentioning that only 1/2 or 2/3 of the max
>installable memory is actually handled by the chipset....


Caching is done by the processor. It's not been done by the chipset since
the old socket 7 days.

slram patch appears to be aimed at the old Pentium chipsets that didn't
cache memory above 64MB. </google>

As the reference poster uses a Duron, this is unlikely to be the cause.
Besides, even with no cache, the kernel should still boot faster than you
can follow it on the screen.

It appears you have a chipset which has built in video which shares memory
with main memory, you're probably experiencing contention for memory
access with the video circuitry. Hence the nice round 32MB before things
normalise again. Either live with it, or buy a cheap PCI/AGP GFX card and
disable the onboard GFX.


>
>HTH,
>
>Mike.
>

Christian


-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug