Found some interesting things, the delays are caused by
1) throttle_vm_writeout()
I removed it, Andrew worries about that, but hopefully there's a
better solution to his worries
2) atime updates
my uml image did not have them turned off
3) UML timer tick does not seem very re
* 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
> > > 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
> > 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:
* 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?
And is there something I can re
* 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
> > 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 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:
> 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), and then returns to the nor
12 matches
Mail list logo
