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

[Mike Brodbelt]

On Wed, 2005-02-23 at 12:32 +0000, Christian Smith wrote:
> On Tue, 22 Feb 2005, Mike Brodbelt wrote:

<snip>

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

Yes, I'd managed to forget that. From P2 architectures on the L2 cache
moved onto the chip - when I originally read about this problem it was
(still mostly) chipset related though.

> 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.

My main machine exhibits the same symptoms that John describes with a
kernel compiled for highmem support. When I first observed the problem
it was a 400Mhz PII, it's now a 1Ghz P3 (still the same motherboard),
and it uses an Intel 440GX chipset. I've seen no explanation for the
symptoms other than memory caching, though that of course doesn't mean
that that is definitely the explanation.

> 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.

While I can't speak for John's machine, mine does not have on board
video, has a separate AGP graphics card, and I'm aware of no reason why
there might conceivably be contention. The boot speed is extremely slow
with highmem support in the kernel - definitely not faster than one can
follow on screen. To boot from cold to an X login took upwards of 10
minutes, IIRR.

> 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.

In my case at least, I don't think video contention is the cause of this
problem.

Mike.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug