Dear Dave,
You wrote:
... 64-bit kernels should basically be drop-in replacements for 32-bit
ones. You can keep userspace 100% 32-bit, and just have a 64-bit
kernel.
Any advice on how I would install a 64-bit kernel, particularly in the
Debian world? Seems to me that on a 32-bit machine,
On Fri, 11 Jan 2013 12:46:15 +1100 paul.sz...@sydney.edu.au wrote:
... I don't believe 64GB of RAM has _ever_ been booted on a 32-bit
kernel without either violating the ABI (3GB/1GB split) or doing
something that never got merged upstream ...
Sorry to be so contradictory:
psz@como:~$
On Fri, 2013-01-11 at 00:01 -0800, Andrew Morton wrote:
On Fri, 11 Jan 2013 12:46:15 +1100 paul.sz...@sydney.edu.au wrote:
... I don't believe 64GB of RAM has _ever_ been booted on a 32-bit
kernel without either violating the ABI (3GB/1GB split) or doing
something that never got merged
Dear Andrew,
Check /proc/slabinfo, see if all your lowmem got eaten up by buffer_heads.
Please see below: I do not know what any of that means. This machine has
been running just fine, with all my users logging in here via XDMCP from
X-terminals, dozens logged in simultaneously. (But, I think I
On 01/10/2013 05:46 PM, paul.sz...@sydney.edu.au wrote:
... I don't believe 64GB of RAM has _ever_ been booted on a 32-bit
kernel without either violating the ABI (3GB/1GB split) or doing
something that never got merged upstream ...
Sorry to be so contradictory:
psz@como:~$ uname -a
On Fri, 11 Jan 2013 22:51:35 +1100
paul.sz...@sydney.edu.au wrote:
Dear Andrew,
Check /proc/slabinfo, see if all your lowmem got eaten up by buffer_heads.
Please see below: I do not know what any of that means. This machine has
been running just fine, with all my users logging in here
Dear Andrew,
Check /proc/slabinfo, see if all your lowmem got eaten up by buffer_heads.
Please see below ...
... Was this dump taken when the system was at or near oom?
No, that was a quiescent machine. Please see a just-before-OOM dump in
my next message (in a little while).
Please send a
Dear Linux-MM,
On a machine with i386 kernel and over 32GB RAM, an OOM condition is
reliably obtained simply by writing a few files to some local disk
e.g. with:
n=0; while [ $n -lt 99 ]; do dd bs=1M count=1024 if=/dev/zero of=x$n;
((n=$n+1)); done
Crash usually occurs after 16 or 32 files
On 01/10/2013 01:58 PM, paul.sz...@sydney.edu.au wrote:
I developed a workaround patch for this particular OOM demo, dropping
filesystem caches when about to exhaust lowmem. However, subsequently
I observed OOM when running many processes (as yet I do not have an
easy-to-reproduce demo of
Dear Dave,
Your configuration has never worked. This isn't a regression ...
... does not mean that we expect it to work.
Do you mean that CONFIG_HIGHMEM64G is deprecated, should not be used;
that all development is for 64-bit only?
... 64-bit kernels should basically be drop-in replacements
On 01/10/2013 04:46 PM, paul.sz...@sydney.edu.au wrote:
Your configuration has never worked. This isn't a regression ...
... does not mean that we expect it to work.
Do you mean that CONFIG_HIGHMEM64G is deprecated, should not be used;
that all development is for 64-bit only?
My last 4GB
Dear Dave,
... I don't believe 64GB of RAM has _ever_ been booted on a 32-bit
kernel without either violating the ABI (3GB/1GB split) or doing
something that never got merged upstream ...
Sorry to be so contradictory:
psz@como:~$ uname -a
Linux como.maths.usyd.edu.au 3.2.32-pk06.10-t01-i386
12 matches
Mail list logo
