On Mon, May 31, 2010 at 10:48:32PM +0100, Richard Purdie wrote:
> On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote:
> > On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> > > I2C-drivers can use the clientdata-pointer to point to private data. As
> > > I2C
> > > devices are no
Now we dynamically allocate the paca array, it takes an extra load
whenever we want to access another cpu's paca. One place we do that a lot
is per cpu variables. A simple example:
DEFINE_PER_CPU(unsigned long, vara);
unsigned long test4(int cpu)
{
return per_cpu(vara, cpu);
}
This takes
On 01.06.2010, at 00:40, Paul Mackerras wrote:
> On Mon, May 31, 2010 at 09:59:13PM +0200, Andreas Schwab wrote:
>
>> Instead of instantiating a whole thread_struct on the stack use only the
>> required parts of it.
>
> ...
>
>> +_GLOBAL(kvm_cvt_fd)
>> +lfd 0,0(r5) /* l
On Mon, May 31, 2010 at 09:59:13PM +0200, Andreas Schwab wrote:
> Instead of instantiating a whole thread_struct on the stack use only the
> required parts of it.
...
> +_GLOBAL(kvm_cvt_fd)
> + lfd 0,0(r5) /* load up fpscr value */
> + MTFSF_L(0)
> + lfs 0,0(r
On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote:
> On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> > I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> > devices are not really unregistered, but merely detached from their driver,
> > it
> > used
Hi Dmitry,
On Mon, 31 May 2010 12:09:12 -0700, Dmitry Torokhov wrote:
> Frankly I'd prefer taking input stuff through my tree with the goal of
> .36 merge window just to minimize potential merge issues. This is a
> simple cleanup patch that has no dependencies, so there is little gain
> from doing
On 31.05.2010, at 21:59, Andreas Schwab wrote:
> Instead of instantiating a whole thread_struct on the stack use only the
> required parts of it.
>
> Signed-off-by: Andreas Schwab
> Tested-by: Alexander Graf
Avi or Marcelo, please pull this in through kvm.git.
Signed-off-by: Alexander Graf
Instead of instantiating a whole thread_struct on the stack use only the
required parts of it.
Signed-off-by: Andreas Schwab
Tested-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_fpu.h | 27 +
arch/powerpc/kernel/ppc_ksyms.c |4 -
arch/powerpc/kvm/book3s.c
Hi Wolfram,
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> devices are not really unregistered, but merely detached from their driver, it
> used to be the drivers obligation to clear this pointer during
Andreas Schwab wrote:
> Alexander Graf writes:
>
>
>> Mind to send it over so I can take a look at it :)? Getting rid of the
>> task_struct structs lying in the stack is certainly a good idea.
>>
>
> Still untested, because rc1 does not boot.
>
Normal guests work great with the patch a
Alexander Graf writes:
> Mind to send it over so I can take a look at it :)? Getting rid of the
> task_struct structs lying in the stack is certainly a good idea.
Still untested, because rc1 does not boot.
Andreas.
---
arch/powerpc/include/asm/kvm_fpu.h | 29 +
arch/powerpc/kv
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> devices are not really unregistered, but merely detached from their driver, it
> used to be the drivers obligation to clear this pointer during remove() or a
Andreas Schwab wrote:
> Alexander Graf writes:
>
>
>> On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote:
>>
>>
>>> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
>>>
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/ppc_ksyms.c |
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote:
> I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> devices are not really unregistered, but merely detached from their driver, it
> used to be the drivers obligation to clear this pointer during remove() or a
I2C-drivers can use the clientdata-pointer to point to private data. As I2C
devices are not really unregistered, but merely detached from their driver, it
used to be the drivers obligation to clear this pointer during remove() or a
failed probe(). As a couple of drivers forgot to do this, it was ag
Alexander Graf writes:
> On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
>>> Signed-off-by: Benjamin Herrenschmidt
>>> ---
>>> arch/powerpc/kernel/ppc_ksyms.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(
On Mon, 2010-05-31 at 11:33 +0200, Alexander Graf wrote:
> > Alex, this is just a temporary fix to remove the build breakage for
> 40x
> > etc... but please, update KVM to just build-in its own.
>
> What's the bad part in reusing the existing code?
I'm not saying we should dup the code, but I'm s
On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote:
> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
>> Signed-off-by: Benjamin Herrenschmidt
>> ---
>> arch/powerpc/kernel/ppc_ksyms.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Alex, this is just a tem
On Thu, 2010-05-27 at 17:39 +0200, Bosi Daniele wrote:
>
> I'd like to avoid this message on the console I'm using because at
> production time this has to be a simple serial port for external
> peripheral connection. (to do this on the command line we'll leave
> empty the "console" field).
I'm n
On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
>
>
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..
>
Right, so the thing I was thinking about is taking the group capacity
into account when determining the capacity for a single cpu.
S
20 matches
Mail list logo
