Re: Problem with recent changes to fs/dcache.c

[Andrew Morton <akpm@osdl.org>]

"Art Haas" <ahaas@airmail.net> wrote:
>
> I'm still trying to debug this, so I've cloned a 2.6.5 tree and added
> some printk() bits to see what it reported. Here's the top of the
> 'dmesg' output. Notice the 'num_phspages' is 45829, so the value I was
> getting in the 2.6.6-rc3 bootup of 46073 is very similar, which suggests
> that the problem _might_ be with the nr_free_pages() call - which leads
> down in the the mmzone code. Here's the dmesg output:
> 
> .......
> Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz).
> Patching kerne l for srmmu[TI Viking/MXCC]/iommu
> 319MB HIGHMEM available.
> On node 0 totalpages: 130409
>   DMA zone: 48666 pages, LIFO batch:11
>   Normal zone: 0 pages, LIFO batch:1
>   HighMem zone: 81743 pages, LIFO batch:16

130409 pages.

> Power off control detected.
> Built 1 zonelists
> Kernel command line: root=/dev/sda1
> PID hash table entries: 2048 (order 11: 16384 bytes)
> Console: colour dummy device 80x25
> calling mem_init()
> Memory: 509676k available (1352k kernel code, 312k data, 116k init,
>    326972k high mem) [f0000000,1ff4f000]
> num_physpages: 45829

That's wrong.

I do think that num_physpages is ripe for removal - we have a number of
ways of calculating much the same thing in generic code, and probably all
users could be changed to use something else anyway.

But short-term we're stuck with it, and there's a bug somewhere in
arch/sparc/'s calculation of this number.