From: Al Viro <[EMAIL PROTECTED]>
That's not enough, unfortunately. If we go that way, we need to add
dependencies on !UML for several options.
[ jdike - "not enough" refers to my patch which enables X86_32 and
RWSEM_XCHGADD_ALGORITHM in UML's Kconfig.i386 ]
Signed-off-by: Al Viro <[EMAIL PROTE
[ This should be merged with uml-fix-no_hz-busy-loop.patch ]
I forgot to have an int-returning function actually return something.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/os-Linux/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.22/arch/um/os-Linux/time.c
==
These four patches should go into 2.6.24. There are two build fixes,
a fix for yesterday's NO_HZ patch, and a workaround for a host bug.
Jeff
--
Work email - jdike at linux dot intel dot com
---
Under the conditions that UML uses it, tcgetattr is guaranteed to
return -EINTR when the console is attached to /dev/ptmx, making
generic_console_write hang because it loops, calling tcgetattr until
it succeeds. This is a host bug - see
http://marc.info/?l=linux-kernel&m=119618990807182&w=2 for th
Fix a UML build breakage introduced by commit
1032c0ba9da5c5b53173ad2dcf8b2a2da78f8b17 - it introduces X86_32, with
many things which UML needs depending on it.
This patch adds definitions of X86_32 and RWSEM_XCHGADD_ALGORITHM to
the UML/i386 Kconfig.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> > Something like:
> >
> > dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
> >
> > and run 'top' or 'watch something' in another terminal, which
> > sometimes completely stops updating during the write.
>
> Are you talking about missing updates for a few seconds, or for
> longer?
* Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 04:35:12PM +0100, Miklos Szeredi wrote:
> > Something like:
> >
> > dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
> >
> > and run 'top' or 'watch something' in another terminal, which
> > sometimes completely stop
On Wed, Nov 28, 2007 at 04:35:12PM +0100, Miklos Szeredi wrote:
> Something like:
>
> dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
>
> and run 'top' or 'watch something' in another terminal, which
> sometimes completely stops updating during the write.
Are you talking about mis
On Wed, Nov 28, 2007 at 04:38:39PM +0100, Miklos Szeredi wrote:
> It doesn't help in this case. I've gotten as far as realizing that
> the latency tracer needs the irqflags tracing
> (Documentation/irqflags-tracing.tx) and that UML doesn't yet support
> that.
Try the patch below - no guarantees,
> > OK, managed to make it compile, but then something goes wrong in
> > tracer_alloc_bootmem().
>
> It needs 32M, and uml has that much by default. Doh.
>
> But something is still wrong:
>
> > /store/quilt/linux/linux mem=64
I'm an idiot, sorry. It should have been mem=64M. No wonder it
did
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > OK, managed to make it compile, but then something goes wrong in
> > tracer_alloc_bootmem().
>
> It needs 32M, and uml has that much by default. Doh.
reduce MAX_TRACE to something like 1024 to make sure allocation is not
an issue. Do you still s
> OK, managed to make it compile, but then something goes wrong in
> tracer_alloc_bootmem().
It needs 32M, and uml has that much by default. Doh.
But something is still wrong:
> /store/quilt/linux/linux mem=64
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can chan
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > so you can define irqs_off_flags to always-0 and you should be able
> > to get pretty good traces still. It should have no functional
> > impact.
>
> OK, managed to make it compile, but then something goes wrong in
> tracer_alloc_bootmem().
try
> so you can define irqs_off_flags to always-0 and you should be able to
> get pretty good traces still. It should have no functional impact.
OK, managed to make it compile, but then something goes wrong in
tracer_alloc_bootmem().
Jeff?
(attaching patch, which goes on top of
latency-tracer-v2.6
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > it doesnt need it - turn IRQOFF_TRACING off.
>
> # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
>
> This seems to be off.
>
> But latency_trace.c uses irqs_disabled_flags(), which is defined in
> only if CONFIG_TRACE_IRQFLAGS_SUPPORT is set.
>
>
> > > On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or
> > > > directory
> > >
> > > For things like this, look at the host's asm/foo.h and see if it's
> > > usable in UML (and contains things that you need).
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> >
> > For things like this, look at the host's asm/foo.h and see if it's
> > usable in UML (and contai
> On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
>
> For things like this, look at the host's asm/foo.h and see if it's
> usable in UML (and contains things that you need). If it is, just
> make a asm-u
> > When writing a big file to a ubd disk, everything in uml slows down to
> > a crawl, even though CPU usage is minimal.
>
> What exactly is your test case?
Something like:
dd if=/host/tmp/bigfile of=/tmp/bigfile bs=1048576 count=100
and run 'top' or 'watch something' in another terminal, wh
On Wed, Nov 28, 2007 at 02:09:45PM +0100, Miklos Szeredi wrote:
> kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
For things like this, look at the host's asm/foo.h and see if it's
usable in UML (and contains things that you need). If it is, just
make a asm-um/foo.h whic
On Wed, Nov 28, 2007 at 01:47:20PM +0100, Miklos Szeredi wrote:
> When writing a big file to a ubd disk, everything in uml slows down to
> a crawl, even though CPU usage is minimal.
What exactly is your test case?
I have some patches which theoretically should help I/O performance
which I've been
On Wed, Nov 28, 2007 at 10:37:53AM +0100, Miklos Szeredi wrote:
> > Do we have any idea which patch this patch fixes?
>
> I seems like a mainline bug, and has been present for some time
> (forever?).
>
> I have no idea why this wasn't noticed earlier.
Not forever, but it's been there for a while
> > > CC kernel/latency_trace.o
> > > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> > > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs.
> > > kernel/latency_trace.c: In function ???trace???:
> > > kernel/latency_trace.c:658: error: impl
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > CC kernel/latency_trace.o
> > kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or directory
> > kernel/latency_trace.c:63:3: error: #error Implement cycles_to_usecs.
> > kernel/latency_trace.c: In function ???trace???:
> > kernel
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > so there's no forced need to use -rt.
>
> Ah, forgotten about that.
>
> Unfortunately the latency tracer patch doesn't compile either:
>
> CC kernel/latency_trace.o
> kernel/latency_trace.c:28:21: error: asm/rtc.h: No such file or director
> * Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > When writing a big file to a ubd disk, everything in uml slows down to
> > a crawl, even though CPU usage is minimal.
> >
> > So I wanted to try the latency tracer from -rt, but it doesn't compile
> > with UML:
>
> note that there are standalo
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> When writing a big file to a ubd disk, everything in uml slows down to
> a crawl, even though CPU usage is minimal.
>
> So I wanted to try the latency tracer from -rt, but it doesn't compile
> with UML:
note that there are standalone patches as wel
When writing a big file to a ubd disk, everything in uml slows down to
a crawl, even though CPU usage is minimal.
So I wanted to try the latency tracer from -rt, but it doesn't compile
with UML:
CC arch/um/kernel/asm-offsets.s
In file included from arch/um/include/sysdep/kernel-offsets.h:2
> On Tue, 27 Nov 2007 17:20:20 -0500 Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Nov 27, 2007 at 09:29:23PM +0100, Miklos Szeredi wrote:
> > > Sure. The patch works for me, but please check that it also makes
> > > sense.
> >
> > I did - it's a straight-forward leak and fix.
> >
>
> Do
29 matches
Mail list logo
