On Wed, Mar 21, 2012 at 3:21 AM, Raghavendra K T
wrote:
> From: Jeremy Fitzhardinge
>
> The code size expands somewhat, and its probably better to just call
> a function rather than inline it.
>
> Signed-off-by: Jeremy Fitzhardinge
> Signed-off-by: Raghavendra K T
> ---
> arch/x86/Kconfig
On Wed, Jan 11, 2012 at 9:22 PM, Rusty Russell wrote:
>
> Amit Shah (12):
> virtio: pci: switch to new PM API
Hmm. Afaik, this is broken, or at least not complete.
Sure, it switches to the new PM API, but it still does the PCI ops itself.
It should not need to - the PCI layer will do the p
On Fri, Dec 23, 2011 at 1:31 AM, Linus Torvalds
wrote:
>
> So the whole thing looks confused. There's never any reason to
> actually use the expensive sfence/rfences at all. Afaik you still just
> want smp_*mb() for all cases.
But note that I haven't thought deeply about it
On Thu, Dec 22, 2011 at 9:16 PM, Rusty Russell wrote:
> This one as a signed tag on github, in case the inline patch was
> the reason you dropped this.
No, and please why do you make your tag-names be your email address?
That's just odd. It seems to be related to some broken SCM system that
think
On Mon, Jan 31, 2011 at 4:16 PM, Rusty Russell wrote:
> Patches should keep coming through Rusty but it
> helps if I'm Cc'd as well.
This commit log makes no sense as being yours. It's clearly frm
Michael, but you're missing that vital piece of information, ie the
"From: Michael S Tsirkin .." lin
On Mon, 19 Oct 2009, Rusty Russell wrote:
>
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git
> master
"Already up-to-date.".
Forgot to push?
Linus
___
Virtualization mailing list
Virtualization@l
On Thu, 23 Apr 2009, Rusty Russell wrote:
>
> From: Christian Borntraeger
>
> The virtio-rng drivers checks for spurious callbacks. Since
> callbacks can be implemented via shared interrupts (e.g. PCI) this
> could lead to guest kernel oopses with lots of virtio devices.
>
> Signed-off-by: Chr
On Mon, 18 Aug 2008, Anthony Liguori wrote:
>
> Nothing. It works just fine. However, I implemented it more verbosely
> because this is the second time we've "fixed" this problem. See
>
> commit bdc1681cdf1ab6a65fa935a2b3f8fc63b20c54ea
> Author: Rusty Russell <[EMAIL PROTECTED]>
> Date: Mo
On Mon, 18 Aug 2008, Anthony Liguori wrote: <
>
> This handles the case where v < vb->num_pages and ensures we get a
> small, negative, s64 as the result.
That's just horrible code.
Maybe the compiler notices that you're doing something stupid, but
basically, please don't do this.
> - r
On Fri, 20 Jun 2008, Ingo Molnar wrote:
>
> okay - Jeremy, could you try the fix below? (or tip/master, i just
> pushed this out)
Actually, don't try that one.
It needs to be a _byte_ registers, so "ir" was wrong. You need "iq".
Linus
_
On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
Yeah, I was a bit worried about that. Gcc sometimes does insane things.
We literally just tested that the asm should only _ever_ be generated with
a constant value, but
On Thu, 19 Jun 2008, Ingo Molnar wrote:
>
> Below is the commit, it needed a small amount of massaging to apply the
> void * -> unsigned long * change in the x86/bitops topic.
Well, that's your bug right there.
The macros very much depended on the pointers being "void *", due to the
pointer
On Wed, 18 Jun 2008, Linus Torvalds wrote:
>
> And yes, the "lock andl" should be noticeably faster than the xchgl.
I dunno. Here's a untested (!!) patch that turns constant-bit
set/clear_bit ops into byte mask ops (lock orb/andb).
It's not exactly pretty. The
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> It's not cmpxchg, just xchg.
> In other words, is:
>
> lock btr $_PAGE_BIT_RW, (%rbx)
Well, we can actually do it as
lock andl $~_PAGE_RW,(%rbx)
although we haven't bothered (I've wanted several times to make
clear_bit() do t
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware by just clearing the bit
atomically. No need to do the cmpxchg games.
Linus
_
ot_commit() writes back the updated pte, makes sure that
> any hardware updates made since ptep_modify_prot_start() are
> preserved.
Ok, I'm fine with this now that it's renamed to be clearly about just
protection bits.
So
Acked-by: Linus Torvalds <[E
On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
> Well, you could use it to update the page and protection bits while preserving
> the AD bits, but I don't think that's very useful.
It's not that it's not "very useful" - it's that it would be TOTALLY
WRONG.
If you change the page and the AD
On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
> This series adds the pte_rmw_start() and pte_rmw_commit() operations,
> which change this sequence to:
>
> ptent = pte_rmw_start(mm, addr, pte);
> ptent = pte_modify(ptent, newprot);
> /* ... */
> pte_rmw_commit(mm, add
On Thu, 25 Oct 2007, Rusty Russell wrote:
> >
> > git diff -M --stat --summary
>
> Thanks, that is much better. I was just happy to locate git diff in the 133
> git commands on my system; finding options 4, 8 and 22 was beyond my skill.
Hey, we give you the power. Actually realizing it al
On Tue, 23 Oct 2007, Rusty Russell wrote:
>
> Well, with that out the way, and some scatterlist fixups, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git
Ok. However, please include a proper diffstat. And by proper, I mean:
git diff -M
On Mon, 22 Oct 2007, Rusty Russell wrote:
>
> First attempt at git, so please pull carefully. I've just put the
> three i386 boot changes in the repo for the moment. If this works I'll pile
> on the 44 lguest patches.
Well, it looked ok, but I had already merged the same patches throug
On Tue, 24 Jul 2007, Rusty Russell wrote:
>
> Indeed, no code changes, and I feel strongly that it should go into
> 2.6.23 because it's *fun*. And (as often complained) there's not
> enough poetry in the kernel.
There's a reason for that.
There once was a lad from Braidwood
W
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 l
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 th
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, 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.
>
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* *eve
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
arch/*
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 s
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, disab
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 x8
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.
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 gene
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 REGIST
101 - 134 of 134 matches
Mail list logo
