On Wed, Mar 22, 2006 at 04:30:39PM +0100, Blaisorblade wrote:
> I remember this, I didn't have many other things to suggest (apart TT mode)
> and that setting is needed anyway (actually it's needed when you go _over_
> 256M per guest).
To be precise, it's necessary when you have UML processes wi
On Wednesday 22 March 2006 12:04, Stefano Melchior wrote:
> On Tue, Mar 21, 2006 at 07:54:08PM +0100, Blaisorblade wrote:
> Dear all,
>
> > No, that crash is likely a race condition and the code treats
> > mem=256{m,M} the same way.
> > Verified in arch/um/kernel/physmem.c:uml_mem_setup and
> > lib
On Wed, Mar 22, 2006 at 12:04:00PM +0100, Stefano Melchior wrote:
> thus the point is if you need to disable TT mode by default, isn't it?
> Now user-mode-linux is in debian "unstable" [1] and I need to provide a
> config file as default configuration for the pkg: you suggested me to act
> this way
On Tuesday 21 March 2006 21:51, Jeff Dike wrote:
> On Tue, Mar 21, 2006 at 07:54:08PM +0100, Blaisorblade wrote:
> > However, test increasing /proc/sys/vm/max_map_count
>
> This only bites you when you have large UML processes - I don't think it
> can cause a crash on boot.
I remember this, I didn
On Tue, Mar 21, 2006 at 07:54:08PM +0100, Blaisorblade wrote:
Dear all,
>
> No, that crash is likely a race condition and the code treats mem=256{m,M}
> the
> same way.
> Verified in arch/um/kernel/physmem.c:uml_mem_setup and lib/cmdline.c:memparse.
>
> However, test increasing /proc/sys/vm/ma
On Tue, Mar 21, 2006 at 07:54:08PM +0100, Blaisorblade wrote:
> However, test increasing /proc/sys/vm/max_map_count
This only bites you when you have large UML processes - I don't think it
can cause a crash on boot.
Jeff
-
On Tuesday 21 March 2006 15:50, Stefano Melchior wrote:
> On Tue, Mar 21, 2006 at 03:26:25PM +0100, Stefano Melchior wrote:
> Dear all,
> [...]
> I also noticed that, from manual page, if you use:
> mem=memory
> This controls how much "physical" memory the kernel
> allocates for the system. The si
On Tue, Mar 21, 2006 at 03:26:25PM +0100, Stefano Melchior wrote:
> - while I added the mem=256M option at the command line, I obtained the
> following error:
> Any suggestion?
Do you have CONFIG_MODE_TT enabled? I think disabling it is the fix for this.
Jeff
On Tue, Mar 21, 2006 at 03:26:25PM +0100, Stefano Melchior wrote:
Dear all,
[...]
I also noticed that, from manual page, if you use:
mem=memory
This controls how much "physical" memory the kernel
allocates for the system. The size is specified as a number
followed by one of ’k’, ’K’, ’m’, ’M’,
Dear all,
I may be wrong but I encountered a strange problem:
- I downloaded a root_fs from http://uml.nagafix.co.uk/ (debian)
- I user my own user-mode-linux pkg for debian (upcoming on debian
unstable);
- I launched the following command:
ste$ linux ubd0=Debian-3.1-x86-root_fs con0=fd:0 con=p
On Monday 24 January 2005 05:41 pm, Henrik Nordstrom wrote:
> On Mon, 24 Jan 2005, Blaisorblade wrote:
> > You'd probably prefer to use the 4G/4G patch from Ingo Molnar, integrated
> > into Fedora kernels, to allow processes to use 4G of virtual address
> > space.
>
> Side note: Fedora apparently d
On Mon, 24 Jan 2005, Blaisorblade wrote:
You'd probably prefer to use the 4G/4G patch from Ingo Molnar, integrated into
Fedora kernels, to allow processes to use 4G of virtual address space.
Side note: Fedora apparently dropped this patch some time ago, reason not
known to me.
* Thu Dec 09 2004 D
On Monday 24 January 2005 09:13, Vaibhav Sharma, Noida wrote:
> Thank you all for ur valuable discussion (temp dir) and suggestions related
> to highmem/PAE and x86_64.
>
> I have another thing to ask related to debugging...i want to check the
> routines which will be involved in the memory manage
On Monday 24 January 2005 11:02, Henrik Nordstrom wrote:
> On Sun, 23 Jan 2005, Rob Landley wrote:
> > The client kernel's highmem suport is unlikely to do much, I'd think.
> > Not unless it's unmapping and remapping multiple mmaps.
It does this, indeed and sadly (that's why it's so slow).
> > (The
On Sunday 23 January 2005 10:51, Rob Landley wrote:
> On Sunday 23 January 2005 03:28 am, Doug Dumitru wrote:
> > Mr. Sharma,
> >
> > What you are trying to do will work, but not for large amounts of
> > memory. UML runs the client using a single user mode memory block as
> > the entire client's c
Jeff Dike wrote:
[EMAIL PROTECTED] said:
But that's not all, what's needed to have *support* for big memory.
Linux needs to have one struct page for each physical mem page, which
in the simple case of UML are placed in one memmap array.
The original poster is interested in the memory scalability
On Monday 24 January 2005 03:13 am, Vaibhav Sharma, Noida wrote:
> According to the design of UML, it has its own VM system. If I have to
> check the scalability limits of the "parent kernel" for memory management,
> will UML be useful..?
Jeff Dike already answered this. (He's the UML maintainer
> Linux needs to have one struct page for each physical mem page, which in
> the
> simple case of UML are placed in one memmap array.
> This array needs to be accessible permanently to the kernel, i.e. it
> has to be in low-mem. AFAIK, one struct page is 44 bytes in size, thus the
> array is about
Henrik Nordstrom wrote:
On Mon, 24 Jan 2005, Rob Landley wrote:
Interesting. I wonder how that works? (PAE on x86 only lets you have
64G.)
Thats only an limitation of the CPU support for PAE. As UML is using
mmap() other limits apply and these limits is mainly set by the UML
pagetable structu
On Mon, 24 Jan 2005, Rob Landley wrote:
Interesting. I wonder how that works? (PAE on x86 only lets you have 64G.)
Thats only an limitation of the CPU support for PAE. As UML is using
mmap() other limits apply and these limits is mainly set by the UML
pagetable structures.
But an individual pr
On Sun, 23 Jan 2005, Rob Landley wrote:
The client kernel's highmem suport is unlikely to do much, I'd think.
Not unless it's unmapping and remapping multiple mmaps. (There's large
file support, but trying to mmap a 5 gig chunk out of a large file can't
work: what would that mean? How could you
mode-linux-devel@lists.sourceforge.net
Cc: Jeff Dike; Vaibhav Sharma, Noida; Doug Dumitru
Subject: Re: [uml-devel] memory
On Sunday 23 January 2005 08:11 pm, Jeff Dike wrote:
> It'll allocate a temp file of the appropriate size. If it's larger
> than what it can use for physica
On Sunday 23 January 2005 08:11 pm, Jeff Dike wrote:
> It'll allocate a temp file of the appropriate size. If it's larger than
> what it can use for physical memory, the rest will be allocated as highmem.
> If you leave 2-level pagetables on, then you're limited to 4G. If you turn
> on 3-level pa
[EMAIL PROTECTED] said:
> I have to build a simulator, to check the scalability limits in memory
> management of linux. For this, the simulator will provide a large
> amount of RAM (in GBs), even if the amout of physical memory is only
> 512MB.
>
> Can UML be used for this purpose? I had seen the
On Sunday 23 January 2005 01:27 pm, Henrik Nordstrom wrote:
> On Sun, 23 Jan 2005, Doug Dumitru wrote:
> > What you are trying to do will work, but not for large amounts of memory.
> > UML runs the client using a single user mode memory block as the entire
> > client's core. Thus the clients core
On Sun, 23 Jan 2005, Doug Dumitru wrote:
What you are trying to do will work, but not for large amounts of memory.
UML runs the client using a single user mode memory block as the entire
client's core. Thus the clients core size is limited to what a single task
can allocate as plain memory.
It
On Sunday 23 January 2005 03:28 am, Doug Dumitru wrote:
> Mr. Sharma,
>
> What you are trying to do will work, but not for large amounts of
> memory. UML runs the client using a single user mode memory block as
> the entire client's core. Thus the clients core size is limited to what
> a single
Vaibhav Sharma, Noida wrote:
Hi,
I have to build a simulator, to check the scalability limits in memory
management of linux. For this, the simulator will provide a large
amount of RAM (in GBs), even if the amout of physical memory is only 512MB.
Can UML be used for this purpose? I had seen the
Title: memory
Hi,
I have to build a simulator, to check the scalability limits in memory management of linux. For this, the simulator will provide a large amount of RAM (in GBs), even if the amout of physical memory is only 512MB.
Can UML be used for this purpose? I had seen the "mem" optio
quot;
missing the fact, that the list wasn't CC'ed
Bodo
------------
Subject:
Re: [uml-devel] Memory corruption/errors?
From:
Bodo Stroesser <[EMAIL PROTECTED]>
Date:
Thu, 23 Dec 2004 13:58:18 +0100
To:
Peter <[EMAIL PROTECTED]>
sser wrote:
I'm forwarding this to the list, because I did a "Reply to all"
missing the fact, that the list wasn't CC'ed
Bodo
------------
Subject:
Re: [uml-devel] Memory corruption/errors?
From:
Bodo Stroesser <[EMAIL
rwarding this to the list, because I did a "Reply to all"
missing the fact, that the list wasn't CC'ed
Bodo
------------
Subject:
Re: [uml-devel] Memory corruption/errors?
From:
Bodo Stroesser <[EMAIL PROTECTED]>
D
I'm forwarding this to the list, because I did a "Reply to all"
missing the fact, that the list wasn't CC'ed
Bodo
--- Begin Message ---
Peter wrote:
I really don't know what fxsr is. But I think I have it. My servers
are dual proc xeons. 2.6.8.1 with skas3 v7 (mostly).
# cat /proc/cpuinfo | g
I'm forwarding this to the list.
Bodo
--- Begin Message ---
I really don't know what fxsr is. But I think I have it. My servers
are dual proc xeons. 2.6.8.1 with skas3 v7 (mostly).
# cat /proc/cpuinfo | grep fxsr
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
Peter wrote:
I don't run TT mode UMLs. So, no I haven't tried that.
I don't know about the sighandler. The program runs as it was listed.
It is running on a 'regular' server (Debian, and/or WBL3) with other
processes running. And the host servers happen to be running other
UMLs. I don't know
I don't run TT mode UMLs. So, no I haven't tried that.
I don't know about the sighandler. The program runs as it was listed.
It is running on a 'regular' server (Debian, and/or WBL3) with other
processes running. And the host servers happen to be running other
UMLs. I don't know if that info
Bodo Stroesser wrote:
Carl wrote:
Hi,
Running the piece of code from the URL below is generating errors on
various UML kernels:
http://downloads.rimuhosting.com/memtest.c
Kernels tested are: 2.4.27, 2.4.27-bs1, 2.6.9-bb4.
Sorry for forgetting to attach the testtool.
Here it is.
Bodo
Different UML h
Carl wrote:
Hi,
Running the piece of code from the URL below is generating errors on
various UML kernels:
http://downloads.rimuhosting.com/memtest.c
Kernels tested are: 2.4.27, 2.4.27-bs1, 2.6.9-bb4.
Different UML host servers have been tried too, and only UMLs running on
SMP (dual Xeon) servers se
Peter wrote:
I don't recall seeing an error where the obs and exp were equal. I saw
plenty where they were not equal.
The code is pretty simple:
double observed = a[i];
double expected = (double) i;
if (observed != expected) {
printf ("failed at i=%u, k=%u (obs %.18g vs exp %.18g)\n",i
I don't recall seeing an error where the obs and exp were equal. I saw
plenty where they were not equal.
The code is pretty simple:
double observed = a[i];
double expected = (double) i;
if (observed != expected) {
printf ("failed at i=%u, k=%u (obs %.18g vs exp %.18g)\n",i,
k,observed, e
Carl wrote:
Hi,
Running the piece of code from the URL below is generating errors on
various UML kernels:
http://downloads.rimuhosting.com/memtest.c
Kernels tested are: 2.4.27, 2.4.27-bs1, 2.6.9-bb4.
Different UML host servers have been tried too, and only UMLs running on
SMP (dual Xeon) servers se
Hi,
Running the piece of code from the URL below is generating errors on
various UML kernels:
http://downloads.rimuhosting.com/memtest.c
Kernels tested are: 2.4.27, 2.4.27-bs1, 2.6.9-bb4.
Different UML host servers have been tried too, and only UMLs running on
SMP (dual Xeon) servers seem to ha
42 matches
Mail list logo