Sorry! I was referring to the SKAS3/4, I forgot the number.
So are the SKAS3/4 still alive ?
I have never tried them, I was waiting for them to get into the mainline.
The normal uml machine is already very good, but if it can be even better,
it would be good news.
> On Tue, Dec 6, 2011 at 11:40
I did not read everything carefully but I thought that with the skas0,
I would see only one uml linux process in the host for the whole uml
machine, and also that it would not take the /dev/shm memory anymore.
Sometimes, with some weak PC or a bad /dev/shm config, if you put too many
machines, th
On Tue, Dec 6, 2011 at 11:40 PM, wrote:
>
> I did not read everything carefully but I thought that with the skas0,
> I would see only one uml linux process in the host for the whole uml
> machine, and also that it would not take the /dev/shm memory anymore.
No.
Maybe your are referring to SKAS3/
Hi Jeff, Richard,
many thanks for your explanations! I think I got it now...
One more question:
On Tue, Dec 6, 2011 at 21:49, Jeff Dike wrote:
> On Tue, Dec 06, 2011 at 07:48:40PM +0100, Riccardo Murri wrote:
>> In addition, *every* syscall generates a SIGTRAP to the UML kernel
>> process, whi
On Tue, Dec 6, 2011 at 10:31 PM, wrote:
>
> Is there still a chance that the skas0 patch will end up in the mainline?
>
It is already in mainline.
--
Thanks,
//richard
--
Cloud Services Checklist: Pricing and Packagin
Is there still a chance that the skas0 patch will end up in the mainline?
> On Tue, Dec 06, 2011 at 07:48:40PM +0100, Riccardo Murri wrote:
>> Sorry again for resurrecting an old thread, but I each time I look
>> into this issue I realize that I haven't quite understood the details...
>
> You
On Tue, Dec 06, 2011 at 07:48:40PM +0100, Riccardo Murri wrote:
> Sorry again for resurrecting an old thread, but I each time I look
> into this issue I realize that I haven't quite understood the details...
You basically have it all right.
> In addition, *every* syscall generates a SIGTRAP to th
Hi,
On Tue, Dec 6, 2011 at 7:48 PM, Riccardo Murri wrote:
>
> If I got it right:
>
> - The UML kernel runs in its own process (hence kernel space
> separation, enforced by the host kernel), which is the parent of
> all the UML processes (one per guest process).
The separation is enforced
Hello,
Sorry again for resurrecting an old thread, but I each time I look
into this issue I realize that I haven't quite understood the details...
On Thu, Oct 13, 2011 at 03:35, Jeff Dike wrote:
> On Thu, Oct 13, 2011 at 01:37:24AM +0200, Riccardo Murri wrote:
>> - however, UML "threads" do shar
Hi Jeff, all,
On Thu, Oct 13, 2011 at 3:35 AM, Jeff Dike wrote:
> UML uses separate address spaces for its processes, thus
> they don't look like threads to anything else, but the bulk of the
> memory (the UML kernel) in those address spaces is shared.
Is it technically feasible to modify UML so
On Thu, Oct 13, 2011 at 01:37:24AM +0200, Riccardo Murri wrote:
> Thus:
>
> - batch system schedulers do righteously consider each UML "thread" as
> a separate process;
>
> - however, UML "threads" do share a large portion of the memory, as
> can be seen from this "ps" output:
>
> PID
Hello,
sorry for resurrecting this old thread, but I need to test my
understanding of the problem and I'd like to ask for a clarification.
On Thu, Aug 4, 2011 at 7:09 PM, richard -rw- weinberger
wrote:
> On Thu, Aug 4, 2011 at 5:42 PM, Riccardo Murri
wrote:
>>
>> I see that each UML instance st
On Thu, Aug 4, 2011 at 5:42 PM, Riccardo Murri wrote:
> Hello,
>
> I see that each UML instance starts a variable number of threads/processes.
>
> I'm using UML in a batch system (Sun Grid Engine 6.2); SGE kills my
> jobs because they exceed the allowed memory reservation. My guess is
> that SGE
13 matches
Mail list logo
