Greetings-

I seem to have developed a need for a single process (R) to use more than
3G of RAM. The system has 6G, and is doing virtually nothing else. Is
there a way to compile 2.6.18 or higher with the so-called hugemem patch
under debian?

Thanks.

----------------------------------------------------------------------
Andrew J Perrin - andrew_perrin (at) unc.edu - http://perrin.socsci.unc.edu
Assistant Professor of Sociology; Book Review Editor, _Social Forces_
University of North Carolina - CB#3210, Chapel Hill, NC 27599-3210 USA
New Book: http://www.press.uchicago.edu/cgi-bi.../00/178592.ctl



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Perrin <clists@perrin.socsci.unc.edu> wrote:

> Greetings-
>
> I seem to have developed a need for a single process (R) to use more
> than 3G of RAM. The system has 6G, and is doing virtually nothing
> else. Is there a way to compile 2.6.18 or higher with the so-called
> hugemem patch under debian?

Do you need to compile your own kernel for some particular reason?

~$ apt-cache show linux-image-2.6.18-4-686-bigmem

[...]

Description: Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4

This package provides the binary image and pre-built loadable modules
for Linux kernel 2.6.18 on Pentium Pro/Celeron/Pentium II/Pentium
III/Pentium 4 with 4-64G RAM machines.

HTH,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 08/03/07 10:28 -0500, Andrew Perrin wrote:
> I seem to have developed a need for a single process (R) to use more than
> 3G of RAM. The system has 6G, and is doing virtually nothing else. Is
> there a way to compile 2.6.18 or higher with the so-called hugemem patch
> under debian?
It looks like hugemem is a redhat thing... I don't know if it is
easy/possible to have it under debian. These kernels are generally heavily
patched.

But even with this patch, a signle process will be limited to less than 4G of
memory. As the hugemem kernels have switching overhead check if you really
can't work in another way.

Regards,

Damien
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8HwYijvYwIbxFwERAkq0AKDsBDw9YDIqWR5q1/0PNIiizZB6YgCfcLl4
IV2ubScULXyxgmdkcsmy5s0=
=w+zr
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/07 15:11, Damien Ferrand wrote:
> On 08/03/07 10:28 -0500, Andrew Perrin wrote:
>> I seem to have developed a need for a single process (R) to use more than
>> 3G of RAM. The system has 6G, and is doing virtually nothing else. Is
>> there a way to compile 2.6.18 or higher with the so-called hugemem patch
>> under debian?
> It looks like hugemem is a redhat thing... I don't know if it is
> easy/possible to have it under debian. These kernels are generally heavily
> patched.
>
> But even with this patch, a signle process will be limited to less than 4G of
> memory. As the hugemem kernels have switching overhead check if you really
> can't work in another way.

Yes, you really need a 64-bit system for a single process to
efficiently use more than 1 (or is it 2?) GB or memory.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8KaOS9HxQb37XmcRAqSuAJ9xGGNB0wyC45G5c7ih82 fHiWBsTACfS2MG
8ygMAVHuRcFDuBpSIDawHnE=
=/25b
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 8 Mar 2007, Ron Johnson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/08/07 15:11, Damien Ferrand wrote:
>> On 08/03/07 10:28 -0500, Andrew Perrin wrote:
>>> I seem to have developed a need for a single process (R) to use more than
>>> 3G of RAM. The system has 6G, and is doing virtually nothing else. Is
>>> there a way to compile 2.6.18 or higher with the so-called hugemem patch
>>> under debian?
>> It looks like hugemem is a redhat thing... I don't know if it is
>> easy/possible to have it under debian. These kernels are generally heavily
>> patched.
>>
>> But even with this patch, a signle process will be limited to less than 4G of
>> memory. As the hugemem kernels have switching overhead check if you really
>> can't work in another way.
>
> Yes, you really need a 64-bit system for a single process to
> efficiently use more than 1 (or is it 2?) GB or memory.
>

The consensus elsewhere seems to be that it's actually 3G per process, but
that's still not enough for this application. Oh well....

ap

----------------------------------------------------------------------
Andrew J Perrin - andrew_perrin (at) unc.edu - http://perrin.socsci.unc.edu
Assistant Professor of Sociology; Book Review Editor, _Social Forces_
University of North Carolina - CB#3210, Chapel Hill, NC 27599-3210 USA
New Book: http://www.press.uchicago.edu/cgi-bi.../00/178592.ctl





--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/07 19:35, Andrew Perrin wrote:
> On Thu, 8 Mar 2007, Ron Johnson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/08/07 15:11, Damien Ferrand wrote:
>>> On 08/03/07 10:28 -0500, Andrew Perrin wrote:
>>>> I seem to have developed a need for a single process (R) to use more
>>>> than
>>>> 3G of RAM. The system has 6G, and is doing virtually nothing else. Is
>>>> there a way to compile 2.6.18 or higher with the so-called hugemem
>>>> patch
>>>> under debian?
>>> It looks like hugemem is a redhat thing... I don't know if it is
>>> easy/possible to have it under debian. These kernels are generally
>>> heavily
>>> patched.
>>>
>>> But even with this patch, a signle process will be limited to less
>>> than 4G of
>>> memory. As the hugemem kernels have switching overhead check if you
>>> really
>>> can't work in another way.
>>
>> Yes, you really need a 64-bit system for a single process to
>> efficiently use more than 1 (or is it 2?) GB or memory.
>>
>
> The consensus elsewhere seems to be that it's actually 3G per process,
> but that's still not enough for this application. Oh well....

Every time I've had a process go into a RAM-gobbling death spiral,
it's died at 1 (or 2) GB. It's been a while since I've seen such a
bug. But then, I just tried this test program, which successfully
allocated 2.4GB (VIRT 2401m & RES 875m):

$ cat testmem3.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv)
{
unsigned long mb = atoi(argv[1]) * 1024 * 1024;
char *p = malloc(mb);
memset(p, 0xDEAD, mb);
sleep(30);
}
$ gcc -o testmem3 testmem3.c
$ ./testmem3 2400





>
> ap
>
> ----------------------------------------------------------------------
> Andrew J Perrin - andrew_perrin (at) unc.edu - http://perrin.socsci.unc.edu
> Assistant Professor of Sociology; Book Review Editor, _Social Forces_
> University of North Carolina - CB#3210, Chapel Hill, NC 27599-3210 USA
> New Book: http://www.press.uchicago.edu/cgi-bi.../00/178592.ctl
>
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8NpkS9HxQb37XmcRAlO5AJ9+zylISLDWfwlpAOlL4G aMpqk/hACfbD8d
wVWAg3E+g0GjZVZCP9RlUpM=
=BtWv
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org