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
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
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
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.
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:
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:
>
> 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
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
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
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
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
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
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
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
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
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
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
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, 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
> > 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
> 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
Andi Kleen wrote:
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.
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but less important
> 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.
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
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*
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.
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 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
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I have this dim memory that ARM has done it that way for a long time
> because it's so expensive to do a "real" cli/sti.
>
> And I think -rt does it for other reasons. It's just more flexible.
-rt doesnt wrap cli/sti anymore: spin_lock_irq*()
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 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
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
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
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
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
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 interrupts?
Yeah,
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
On Mon, 19 Mar 2007, Jeremy Fitzhardinge wrote:
>
> 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.
On
\
> 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
Am Di 20.03.2007 06:54 schrieb Jeremy Fitzhardinge <[EMAIL PROTECTED]>:
> 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),
Am Di 20.03.2007 06:54 schrieb Jeremy Fitzhardinge [EMAIL PROTECTED]:
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
On Mon, 19 Mar 2007, Jeremy Fitzhardinge wrote:
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.
On x86, yes.
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
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 interrupts?
Yeah, disable
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 linux-kernel
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
* Linus Torvalds [EMAIL PROTECTED] wrote:
I have this dim memory that ARM has done it that way for a long time
because it's so expensive to do a real cli/sti.
And I think -rt does it for other reasons. It's just more flexible.
-rt doesnt wrap cli/sti anymore: spin_lock_irq*() doesnt
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
Andi Kleen wrote:
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.
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but less important
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
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
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.
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
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
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.
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
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.
>>
>
>
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
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
> 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
>
> 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
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
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
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
>
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
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
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
* 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, 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
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
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
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
1 - 100 of 161 matches
Mail list logo
