From: "Matthew Starzewski" <mstarzewski@xes-inc.com>
To: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
Cc: <linux-mips@linux-mips.org>
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Date: Wed, 15 Dec 2004 09:02:48 -0600 [thread overview]
Message-ID: <064501c4e2b7$2591c820$0d00340a@matts> (raw)
In-Reply-To: 41B9CA72.7030208@enix.org
> This may be an ancillary effect of what's mentioned above, but when
num_physpages
> grows in size, nr_free_pages doesn't track with it, so in void
vfs_caches_init(unsigned long
> mempages) and the like, you get a horrible underflow condition:
>
> /* code */
> printk("MJS - nr_free_pages():0x%X\n", nr_free_pages());
> printk("MJS - OLD mempages:0x%X\n", mempages);
> reserve = (mempages - nr_free_pages()) * 3/2;
> mempages -= reserve;
> printk("MJS - NEW reserve:0x%X mempages:0x%X\n",
> reserve, mempages);
>
> /* printout */
> MJS - nr_free_pages():0x1E9A0
> MJS - OLD mempages:0x90000
> MJS - NEW reserve:0xAA190 mempages:0xFFFE5E70
I thought I'd wrap up this thread, especially with the HIGHMEM thread still
going around:
http://www.linux-mips.org/archives/linux-mips/2004-12/msg00141.html
The above underflow *was* my problem. I was working in 2.6.6-rc3 before;
with the patch below from 2.6.7-rc1 everything works fine.
# VFS cache sizing fix for small machines
http://linux.bkbits.net:8080/linux-2.6/diffs/fs/dcache.c@1.81?nav=index.html
|src/|src/fs|hist/fs/dcache.c
# BitKeeper ChangeSet
http://linux.bkbits.net:8080/linux-2.6/cset@1.1717.23.50?nav=index.html|src/
|src/fs|related/fs/dcache.c
In fs/dcache.c, vfs_caches_init():
< reserve = (mempages - nr_free_pages()) * 3/2;
> reserve = min((mempages - nr_free_pages()) * 3/2, mempages - 1);
Regards,
Matt
----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
To: "Matthew Starzewski" <mstarzewski@xes-inc.com>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, December 10, 2004 10:10 AM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode,
revisited
WARNING: multiple messages have this Message-ID (diff)
From: "Matthew Starzewski" <mstarzewski@xes-inc.com>
To: Thomas Petazzoni <thomas.petazzoni@enix.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited
Date: Wed, 15 Dec 2004 09:02:48 -0600 [thread overview]
Message-ID: <064501c4e2b7$2591c820$0d00340a@matts> (raw)
Message-ID: <20041215150248.qw5pQLWCZm27_uvHyBQgjj7ZFK0jKiw6_t338DGV128@z> (raw)
In-Reply-To: 41B9CA72.7030208@enix.org
> This may be an ancillary effect of what's mentioned above, but when
num_physpages
> grows in size, nr_free_pages doesn't track with it, so in void
vfs_caches_init(unsigned long
> mempages) and the like, you get a horrible underflow condition:
>
> /* code */
> printk("MJS - nr_free_pages():0x%X\n", nr_free_pages());
> printk("MJS - OLD mempages:0x%X\n", mempages);
> reserve = (mempages - nr_free_pages()) * 3/2;
> mempages -= reserve;
> printk("MJS - NEW reserve:0x%X mempages:0x%X\n",
> reserve, mempages);
>
> /* printout */
> MJS - nr_free_pages():0x1E9A0
> MJS - OLD mempages:0x90000
> MJS - NEW reserve:0xAA190 mempages:0xFFFE5E70
I thought I'd wrap up this thread, especially with the HIGHMEM thread still
going around:
http://www.linux-mips.org/archives/linux-mips/2004-12/msg00141.html
The above underflow *was* my problem. I was working in 2.6.6-rc3 before;
with the patch below from 2.6.7-rc1 everything works fine.
# VFS cache sizing fix for small machines
http://linux.bkbits.net:8080/linux-2.6/diffs/fs/dcache.c@1.81?nav=index.html
|src/|src/fs|hist/fs/dcache.c
# BitKeeper ChangeSet
http://linux.bkbits.net:8080/linux-2.6/cset@1.1717.23.50?nav=index.html|src/
|src/fs|related/fs/dcache.c
In fs/dcache.c, vfs_caches_init():
< reserve = (mempages - nr_free_pages()) * 3/2;
> reserve = min((mempages - nr_free_pages()) * 3/2, mempages - 1);
Regards,
Matt
----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@enix.org>
To: "Matthew Starzewski" <mstarzewski@xes-inc.com>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, December 10, 2004 10:10 AM
Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode,
revisited
next prev parent reply other threads:[~2004-12-15 15:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 22:49 Using more than 256 MB of memory on SB1250 in 32-bit mode, revisited Matthew Starzewski
2004-12-09 22:49 ` Matthew Starzewski
2004-12-10 8:46 ` Thomas Petazzoni
2004-12-10 13:02 ` Maciej W. Rozycki
2004-12-10 14:46 ` Matthew Starzewski
2004-12-10 14:46 ` Matthew Starzewski
2004-12-10 16:10 ` Thomas Petazzoni
2004-12-15 15:02 ` Matthew Starzewski [this message]
2004-12-15 15:02 ` Matthew Starzewski
2004-12-15 14:56 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='064501c4e2b7$2591c820$0d00340a@matts' \
--to=mstarzewski@xes-inc.com \
--cc=linux-mips@linux-mips.org \
--cc=thomas.petazzoni@enix.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox