From: Majid S. <ms...@no...> - 2005-05-30 18:59:12
|
> UML uses multiple processes for it's buisness. With Skas UML is just one process as it appears on the Host, or do you mean something else. >When host is > SMP, these can be mapped to different cpu's, and when > interprocess stuff is to occure, cpu's have to sync. > I saw the syscall about 300% slower, it does not make sense due to interprocess. IT should not be that slow, unless missing UML implementation > Also, some few kernel things is slower on SMP, while > user-space things that are not related, and multithreaded > apps run faster. > > Stian > > |
From: Majid S. <ms...@no...> - 2005-05-31 14:41:38
|
Yes. And I am trying fork stress test. Majid. > -----Original Message----- > From: Jeff Dike [mailto:jd...@ad...] > Sent: Tuesday, May 31, 2005 9:58 AM > To: Salame, Majid [CAR:2V62:EXCH] > Cc: use...@li... > Subject: Re: [uml-devel] Slower system call with SMP > > > > The cost of a system call it seems to be higher when > > Running a RHE host with dual CPU (SMP turned on) and the image is > > patched with skas patch. > > > > Doe that make sense ? Doing the same test by disabling SMP on the > > host, and results are much faster. > > What exactly was the test? A getpid loop? > > Jeff > > |
From: Blaisorblade <bla...@ya...> - 2005-07-27 16:39:27
|
On Monday 30 May 2005 20:58, Majid Salame wrote: > > UML uses multiple processes for it's buisness. > With Skas UML is just one process as it appears on the Host, or do you mean > something else. No, it's at least two (+ possible service threads): one is the thread executing kernel code, which ptraces another thread which executes userspace code. > >When host is > > SMP, these can be mapped to different cpu's, and when > > interprocess stuff is to occure, cpu's have to sync. It's not just interprocess comunication. Those two threads could be running on two different processors (which will happen very likely, I fear, if UML is the only thing running, and can happen even without this - I don't think scheduler optimizations consider ptrace() as something needing to join threads together). > I saw the syscall about 300% slower, it does not make sense due to > interprocess. > IT should not be that slow, unless missing UML implementation I think it could, if the two threads run on different processors. Luckily, you can stop the host kernel from doing that: there should be a control option in /proc/<pid>, something like cpus_allowed. Ok, let's assume you talk about SKAS (I'm not expert in TT implementation, should check a couple of things, but you said you use SKAS). Well, it makes sense. In late days I've been studying signal delivery code, and for UML operations, to have a page fault in the guest, what happens is that the guest takes a SIGSEGV. That signal must be intercepted by the UML kernel thread. Sadly, this is largely suboptimal in Linux. In fact, you have, at signal delivery time, to wake up the guest thread (possibly via inter-processor comunication, which is an IPI), which will then have to wake up its tracer (and if that's on a different CPU, that's through an IPI), and then get back to wake up the thread itself. > > Also, some few kernel things is slower on SMP, while > > user-space things that are not related, and multithreaded > > apps run faster. > > Stian -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |