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
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 miscomputes the memory usage by computing the total over all
thread
14 matches
Mail list logo
