From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 21 Mar 2007 11:03:14 +1100
Linus Torvalds writes:
We should just do this natively. There's been several tests over the years
saying that it's much more efficient to do sti/cli as a simple store, and
handling the oops, we got an
Linus Torvalds [EMAIL PROTECTED] writes:
On Mon, 19 Mar 2007, Jeremy Fitzhardinge wrote:
Actually, it still does need a temp register. The sequence for cli is:
mov %fs:xen_vcpu, %eax
movb $1,1(%eax)
We should just do this natively. There's been several tests over the years
Eric W. Biederman wrote:
Looking at the above code snippet. I guess it is about time to
merge our per_cpu and pda variables...
Rusty has a nice patch series to do just that; I think he's still
looking for a taker.
J
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Eric W. Biederman wrote:
If that is the case. In the normal kernel what would
the the oops, we got an interrupt code do?
I assume it would leave interrupts disabled when it returns?
Like we currently do with the delayed disable of normal
But I was throwing that out as a long-term thing. I'm not claiming it's
trivial, but it should be doable.
One thing I was pondering was to replace the expensive popfs with
bt $IF,(%rsp)
jnc 1f
sti
1:
But would be mostly a P4 optimization again and I'm not 100% sure it is
worth it.
-Andi
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but less important than in P4 days.
Well most of Intel 64bit is P4 -- and Intel is still shipping
millions more of them each quarter.
This could change character completely if used at the tail of a function
where you now
Jeremy Fitzhardinge wrote:
Yeah, disable interrupts, and set a flag that the fake sti can test, and
just return without doing anything.
(You may or may not also need to do extra work to Ack the hardware
interrupt etc, which may be irq-controller specific. Once the CPU has
accepted the
On Tue, 2007-03-20 at 09:58 -0600, Eric W. Biederman wrote:
Looking at the above code snippet. I guess it is about time to
merge our per_cpu and pda variables...
Indeed, thanks for the prod. Now 2.6.21-rc4-mm1 is out, I'll resend the
patches.
Cheers,
Rusty.
-
To unsubscribe from this list:
On Tue, Mar 20, 2007 at 09:31:58AM -0700, Jeremy Fitzhardinge wrote:
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Eric W. Biederman wrote:
If that is the case. In the normal kernel what would
the the oops, we got an interrupt code do?
I assume it would leave interrupts disabled when
Matt Mackall wrote:
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get set after this */
Why not? Oh, I see. intr_mask is inverted
Zachary Amsden wrote:
I think Jeremy's idea was to have interrupt handlers leave interrupts
disabled on exit if pda.intr_mask was set. In which case, they would
bypass all work and we could never get preempted.
Yes, I was worried that if we left the isr without actually handling the
On Tue, Mar 20, 2007 at 03:08:19PM -0800, Zachary Amsden wrote:
Matt Mackall wrote:
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get
Linus Torvalds writes:
We should just do this natively. There's been several tests over the years
saying that it's much more efficient to do sti/cli as a simple store, and
handling the oops, we got an interrupt while interrupts were disabled as
a special case.
I have this dim memory
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I think Jeremy's idea was to have interrupt handlers leave interrupts
disabled on exit if pda.intr_mask was set. In which case, they would
bypass all work and we could never get preempted.
Yes, I was worried that if we left the isr
Matt Mackall wrote:
On Tue, Mar 20, 2007 at 09:31:58AM -0700, Jeremy Fitzhardinge wrote:
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Eric W. Biederman wrote:
If that is the case. In the normal kernel what would
the the oops, we got an interrupt code do?
I assume it
On Tue, 20 Mar 2007, Zachary Amsden wrote:
void local_irq_restore(int enabled)
{
pda.intr_mask = enabled;
/*
* note there is a window here where softirqs are not processed by
* the interrupt handler, but that is not a problem, since it will
* get done here in the outer
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
void local_irq_restore(int enabled)
{
pda.intr_mask = enabled;
/*
* note there is a window here where softirqs are not processed by
* the interrupt handler, but that is not a problem, since it will
* get done
On Tue, 20 Mar 2007, Zachary Amsden wrote:
Actually, I was thinking the irq handlers would just not mess around with
eflags on the stack, just call the chip to ack the interrupt and re-enable
hardware interrupts when they left, since that is free anyway with the iret.
No can do. Think
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
Actually, I was thinking the irq handlers would just not mess around with
eflags on the stack, just call the chip to ack the interrupt and re-enable
hardware interrupts when they left, since that is free anyway with the iret.
\
I'm conflicted about the dwarf unwinder. I was off doing other things
at the time so I missed the pain, but I do have a distinct recollection of
the back traces on x86_64 being distinctly worse the on i386.
The only case were i386 was better was with frame pointers, which
was never fully
Eric W. Biederman wrote:
I'm conflicted about the dwarf unwinder. I was off doing other things
at the time so I missed the pain, but I do have a distinct recollection of
the back traces on x86_64 being distinctly worse the on i386. Lately
I haven't seen that so it may be I was
Andi Kleen [EMAIL PROTECTED] writes:
I'm conflicted about the dwarf unwinder. I was off doing other things
at the time so I missed the pain, but I do have a distinct recollection of
the back traces on x86_64 being distinctly worse the on i386.
The only case were i386 was better was with
On Tue, Mar 20, 2007 at 10:25:20AM -0600, Eric W. Biederman wrote:
What I recall observing is call traces that made no sense. Not just
extra noise in the stack trace but things like seeing a function that
has exactly one path to it, and not seeing all of the functions on
that path in the call
On Tue, 20 Mar 2007, Andi Kleen wrote:
No, me and Jan fixed all reported bugs as far as I know.
No you did not. You didn't fix the ones I reported. Which is why it got
removed, and will not get added back until there is another maintainer.
The ones I reported were all about trusting the
On Tue, Mar 20, 2007 at 09:52:42AM -0700, Linus Torvalds wrote:
The ones I reported were all about trusting the stack contents implicitly,
The latest version added the full double check you wanted - every
new RSP is validated against the current stack or the exception stacks.
and assuming
On Tue, 20 Mar 2007, Andi Kleen wrote:
The code never did that. In fact many of the problems we had initially
especially came out of that -- the fallback code that would handle
this case wasn't fully correct.
I don't keep my emails any more, but you *never* fixed the problems in
On Tue, Mar 20, 2007 at 10:27:00AM -0700, Linus Torvalds wrote:
On Tue, 20 Mar 2007, Andi Kleen wrote:
The code never did that. In fact many of the problems we had initially
especially came out of that -- the fallback code that would handle
this case wasn't fully correct.
I don't
On Tue, 20 Mar 2007, Andi Kleen wrote:
So what is your proposed alternative to handle long backtraces?
You didn't answer that question. Please do, I'm curious about your thoughts
in this area.
the thing is, I'd rather see a long backtrace that is hard to decipher but
that *never* *ever*
On Tue, Mar 20, 2007 at 11:49:39AM -0700, Linus Torvalds wrote:
On Tue, 20 Mar 2007, Andi Kleen wrote:
So what is your proposed alternative to handle long backtraces?
You didn't answer that question. Please do, I'm curious about your thoughts
in this area.
the thing is, I'd
Because that's really the issue: do you want a pretty backtrace, or do
you want one that is rock solid but has some crud in it.
I just want an as exact backtrace as possible. I also think
that we can make the unwinder robust enough.
Any reason you can't put the exact back trace in [xxx]
On Tue, Mar 20, 2007 at 09:39:18PM +, Alan Cox wrote:
Because that's really the issue: do you want a pretty backtrace, or do
you want one that is rock solid but has some crud in it.
I just want an as exact backtrace as possible. I also think
that we can make the unwinder robust
On Tue, 20 Mar 2007, Andi Kleen wrote:
On Tue, Mar 20, 2007 at 11:49:39AM -0700, Linus Torvalds wrote:
the thing is, I'd rather see a long backtrace that is hard to decipher but
that *never* *ever* causes any additional problems, over a pretty one.
Well it causes additional
On Tue, 20 Mar 2007, Andi Kleen wrote:
Linus is worried about the unwinder crashing -- that wouldn't help with that.
And to make it clear: this is not a theoretical worry. It happened many
times over the months the unwinder was in.
It was supposed to help debugging, but it made bugs that
On Tue, 20 Mar 2007 21:23:52 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
Well it causes additional problems. We had some cases where it was really
hard to distingush garbage and the true call chain.
yes, for some reason the naive backtraces seem to have got messier and messier
over
the years
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu,
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining DOES NOT CLOBBER AS MANY
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
On Mon, 19 Mar 2007, Linus Torvalds wrote:
So *please* don't believe that you can make it as cheap to have some
automatic fixup of two sequences, one inlined and one as a call. It may
look so when you look at the single instruction generated, but you're
ignoring all the instructions
Eric W. Biederman wrote:
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient
Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 12:10:08 -0700
All this is doable; I'd probably end up hacking boot/compressed/relocs.c
to generate the appropriate reloc table. My main concern is hacking the
kernel build process itself; I'm unsure of what it would actually
David Miller wrote:
Another point worth making is that for function calls you
can fix things up lazily if you want.
[...]
In fact forget I mentioned this idea :)
OK :) I think we'll only ever want to bind to a hypervisor once, since
the underlying hypervisor can't change on the fly
Possibly not, but I'd like to be able to say with confidence that
running a PARAVIRT kernel on bare hardware has no performance loss
compared to running a !PARAVIRT kernel. There's the case of small
instruction sequences which have been replaced with calls (such as
sti/cli/push;popf/etc),
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller
Jeremy Fitzhardinge wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
have a sequence like:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
If we then work out in each direction and see matched push/pops,
then we know what registers can be trashed in the call. This also
allows us to determine the callsite size, and therefore how much space
we need for inlining.
No, that is
Rusty Russell wrote:
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done
On Mon, 2007-03-19 at 18:00 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
*This* was the reason that the current hand-coded calls only clobber %
eax. It was a compromise between native (no clobbers) and others (might
need a reg).
I still don't think this was a good trade.
...
Xen
Zachary Amsden wrote:
For VMI, the default clobber was cc, and you need a way to allow at
least that, because saving and restoring flags is too expensive on x86.
According to lore (Andi, I think), asm() always clobbers cc.
I still don't think this was a good trade. The primary motivation
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Yes. All inline assembly tells gcc what registers are clobbered
and it fills in the tables. Hand clobbering in inline assembly cannot
be expressed with the current toolchain, so we moved all those
out of line.
Andi Kleen wrote:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
This cannot right now be expressed as inline assembly in the unwinder at all
because there is no way to inject the push/pops into the compiler generated
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:57:28 +0100
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
It's inability to handle sequences like the above sounds to me like
a very good argument to _not_ merge the unwinder back into the tree.
The unwinder can handle it fine, it is just that gcc right now cannot
be taught to generate correct unwind tables for it. If paravirt ops
is widely used i
On Mon, 19 Mar 2007, Andi Kleen wrote:
Initially we had some bugs that accounted for near all failures, but they
were all fixed in the latest version.
No. The real bugs were that the people involved wouldn't even accept that
unwinding information was inevitably buggy and/or incomplete.
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time on :-)
Good call. Dwarf2 unwinding
David Miller [EMAIL PROTECTED] writes:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time
From: Rusty Russell [EMAIL PROTECTED]
Date: Sat, 17 Mar 2007 21:33:58 +1100
On Fri, 2007-03-16 at 13:38 -0700, Jeremy Fitzhardinge wrote:
David Miller wrote:
Perhaps the problem can be dealt with using ELF relocations.
There is another case, discussed yesterday on netdev, where
David Miller wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
Instead
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
That wouldn't handle inlines
Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap like that. Just say no...
The bigger problem is that you don't know what registers you can
clobber. For the pv_ops in hand-written asm, that a big pain. The code
either has to assume the worst, or the relocator has to do something
more sophisticated (like look for push/pop pairs surrounding the call,
perhaps?).
You
Andi Kleen wrote:
You could use the dwarf2 unwind tables. They have exact information
what register has what. But it would likely get complicated.
Yes. And would they be accurate for hand-written asm, which is where we
have this problem?
J
-
To unsubscribe from this list: send the line
On Sun, Mar 18, 2007 at 10:29:10AM -0700, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
You could use the dwarf2 unwind tables. They have exact information
what register has what. But it would likely get complicated.
Yes. And would they be accurate for hand-written asm, which is where we
Andi Kleen wrote:
Yes. All inline assembly tells gcc what registers are clobbered
and it fills in the tables. Hand clobbering in inline assembly cannot
be expressed with the current toolchain, so we moved all those
out of line.
But again I'm not sure it will work anyways. For once you would
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu, you'd be
patching up indirect calls and crap
On Fri, 2007-03-16 at 13:38 -0700, Jeremy Fitzhardinge wrote:
David Miller wrote:
Perhaps the problem can be dealt with using ELF relocations.
There is another case, discussed yesterday on netdev, where run-time
resolution of ELF relocations would be useful (for
very-very-very-read-only
David Miller wrote:
Perhaps the problem can be dealt with using ELF relocations.
There is another case, discussed yesterday on netdev, where run-time
resolution of ELF relocations would be useful (for
very-very-very-read-only variables) so if it can solve this problem
too it would be nice to
67 matches
Mail list logo
