From: Pierre Beck <mail@pierre-beck.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 3.6-rc7 32-bit PAE miscalculates dirty page limits
Date: Mon, 01 Oct 2012 23:10:47 +0200 [thread overview]
Message-ID: <506A06B6.50800@pierre-beck.de> (raw)
In-Reply-To: <506894D5.5060101@zytor.com>
Hi,
when I installed the original setup, there were no 64-bit PC CPUs. It's
been kept up-to-date, changed hardware whenever necessary. But a shift
from 32-bit to 64-bit isn't as simple as it seems.
I tried 64-bit kernel with 32-bit userspace. It failed. The installed
DVB-S tuner driver messed up the stream. I *guess* there's some little /
big endian issue between userspace program (vdr, dvbhddevice) and driver
(sff716x_ff which is still in experimental media stack), and it *may* be
resolved by upgrading userspace to 64-bit as well.
I do consider the option of upgrading to 64-bit userspace. My
distribution Debian doesn't provide a clean way to do so in-place,
though. There are HOWTOs on the topic with warnings varying between 'do
not attempt, will eat your data' and 'worked for the author, YMMV'. That
scared me off for now. Instead, a clean install and copying /etc will be
my best option and with LVM in place I'm sure I will eventually upgrade
sooner or later.
Personally, I don't need a fix anyways, since I found the stated
workaround and can live with that. But what about other folks who
upgrade their PC? They won't know what hit them when their new PC crawls
because disk is trashed.
Greetings,
Pierre Beck
On 30.09.2012 20:52, H. Peter Anvin wrote:
> On 09/30/2012 02:38 AM, Pierre Beck wrote:
>> Hi,
>>
>> there seems to be a bug in either ext4 or VM code triggered with 16 GB
>> memory when compiled with 32-bit and PAE. dirty_background_ratio
>> defaults to 10, dirty_ratio to 20. But in effect, dirty pages are
>> strongly limited (zero or negative?). I observed extreme I/O wait states
>> and slow disk access. A quick cure was to set dirty_bytes and
>> dirty_background_bytes to sane values, overriding the ratios. An
>> educated guess: the result of dirty_ratio calculation is stored as an
>> unsigned 32-bit integer and overflows?
>>
>
> Seriously, why are you running a 32-bit kernel on memory sizes this
> large? Yes, in theory it should work up to 64 GB but claims are that
> the kernel doesn't even boot if you try...
>
> -hpa
next prev parent reply other threads:[~2012-10-01 21:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-30 9:38 3.6-rc7 32-bit PAE miscalculates dirty page limits Pierre Beck
2012-09-30 18:52 ` H. Peter Anvin
2012-10-01 21:10 ` Pierre Beck [this message]
2012-10-01 21:52 ` Borislav Petkov
2012-10-01 21:53 ` H. Peter Anvin
2012-10-01 21:59 ` Borislav Petkov
2012-10-01 22:00 ` H. Peter Anvin
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=506A06B6.50800@pierre-beck.de \
--to=mail@pierre-beck.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.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