I can't say I'm understading these traces very well, but here's a
snippet that looks a bit strange. I'm running 'while true; do date;
done' in parallel with the dd.
For some time it is doing 100% CPU as expected, then it goes into a
second or so of mosty idle (afaics), and then returns to the nor
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I can't say I'm understading these traces very well, but here's a
> snippet that looks a bit strange. I'm running 'while true; do date;
> done' in parallel with the dd.
>
> For some time it is doing 100% CPU as expected, then it goes into a
> sec
> > I can't say I'm understading these traces very well, but here's a
> > snippet that looks a bit strange. I'm running 'while true; do date;
> > done' in parallel with the dd.
> >
> > For some time it is doing 100% CPU as expected, then it goes into a
> > second or so of mosty idle (afaics),
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > how come UML idled for 30 msecs here, while the workload was
> > supposed to be CPU-bound? It's not IO bound anywhere, right? No SMP
> > artifacts either, right?
>
> Yes. The UML kernel is UP, and I don't think 'date' or 'bash' want to
> do any
[I forgot to cc the uml-devel list while sending the patch.]
This patch brings back the functionality of stopping user mode linux
with the help of mconsole.
I tested it for six hours and read the code which could be impacted by
this change, so it should work fine, but I am very inexperienced and
This patch removes one more unused variable from the uml code.
This time the variable is removed from mconsole_stack.
I tested this together with my mconsole stopping patch, so it should
work just fine.
Karol Swietlicki
Signed-off-by: Karol Swietlicki <[EMAIL PROTECTED]>
---
diff -rupN orig/arc
> > I can't say I'm understading these traces very well, but here's a
> > snippet that looks a bit strange. I'm running 'while true; do date;
> > done' in parallel with the dd.
> >
> > For some time it is doing 100% CPU as expected, then it goes into a
> > second or so of mosty idle (afaics),
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > to get symbolic stack backdumps for the wakeup points, and add
> > trace_special_sym() calls to generate extra stackdump entries at
> > arbitrary places. schedule() does not have it right now - it might
> > make sense to add it.
>
> OK, this hel
[ This should accompany git-x86.patch to mainline ]
git-x86.patch introduces asm-x86/asm.h. UML needs to follow this with
an asm/asm.h of its own.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
include/asm-um/asm.h |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6.22/include/as
[ 2.6.25 material ]
Style fixes in arch/um/os-Linux/irq.c and arch/um/os-Linux/sigio.c:
Updated copyrights
trimmed includes
added severity indicators to printks
CodingStyle fixes
turned an bunch of panics into printks
call some libc functions directl
[ 2.6.25 material ]
UML still needed some work in order to allow CFLAGS to be passed in
from the command line.
USER_CFLAGS is produced from KBUILD_CFLAGS in part by removing all the
-I switches. This is so that kernel headers don't accidentally get
pulled into libc files. However, a common use
On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> date-7119 0 15636591us!: schedule (0 0)
> bash-502 0 15643908us!: schedule (0 0)
> bash-502 0 15646250us!: schedule (0 0)
How exactly did you end up getting this data?
And is there something I can re
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> > date-7119 0 15636591us!: schedule (0 0)
> > bash-502 0 15643908us!: schedule (0 0)
> > bash-502 0 15646250us!: schedule (0 0)
>
> How exactly did you end u
> > On Thu, Nov 29, 2007 at 11:19:40AM +0100, Miklos Szeredi wrote:
> > > date-7119 0 15636591us!: schedule (0 0)
> > > bash-502 0 15643908us!: schedule (0 0)
> > > bash-502 0 15646250us!: schedule (0 0)
> >
> > How exactly did you end up getting this data?
This:
> > > to get symbolic stack backdumps for the wakeup points, and add
> > > trace_special_sym() calls to generate extra stackdump entries at
> > > arbitrary places. schedule() does not have it right now - it might
> > > make sense to add it.
> >
> > OK, this helped.
> >
> > It looks like the de
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > heh :-) Scheduling isnt hard either - and looking at traces
> > (especially with mcount_enabled=1) certainly helps.
>
> I still don't know what mcount_enabled=1 should do. I didn't see any
> difference in the trace after enabling it.
if you bui
16 matches
Mail list logo
