Nicolas Pitre writes:
> On Tue, 12 Nov 2013, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > On Tue, 12 Nov 2013, Ben Dooks wrote:
>> >
>> >> Given these are single instructoins for ARM, is it possible we could
>> >> make a table of all the callers and fix them up when we initialise
>>
On Tue, 12 Nov 2013, Nicolas Pitre wrote:
> On Tue, 12 Nov 2013, Måns Rullgård wrote:
>
> > It might be possible to extract this information from relocation tables.
>
> True, but only for individual .o files. Once the linker puts them
> together the information is lost, and trying to infer wha
On Tue, 12 Nov 2013, Måns Rullgård wrote:
> Nicolas Pitre writes:
>
> > On Tue, 12 Nov 2013, Ben Dooks wrote:
> >
> >> Given these are single instructoins for ARM, is it possible we could
> >> make a table of all the callers and fix them up when we initialise
> >> as we do for the SMP/UP case an
On Tue, 12 Nov 2013, Måns Rullgård wrote:
> Nicolas Pitre writes:
>
> > What about this patch which I think is currently your best option. Note
> > it would need to use the facilities from asm/opcodes.h to make it endian
> > agnostic.
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/ke
Nicolas Pitre writes:
> On Tue, 12 Nov 2013, Ben Dooks wrote:
>
>> Given these are single instructoins for ARM, is it possible we could
>> make a table of all the callers and fix them up when we initialise
>> as we do for the SMP/UP case and for page-offset?
>
> Not really. Calls to those functi
On Tue, 12 Nov 2013, Ben Dooks wrote:
> Given these are single instructoins for ARM, is it possible we could
> make a table of all the callers and fix them up when we initialise
> as we do for the SMP/UP case and for page-offset?
Not really. Calls to those functions are generated by the compiler
Nicolas Pitre writes:
> What about this patch which I think is currently your best option. Note
> it would need to use the facilities from asm/opcodes.h to make it endian
> agnostic.
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 6a1b8a81b1..379cffe4ab 100644
> ---
On 12/11/13 14:04, Russell King - ARM Linux wrote:
On Tue, Nov 12, 2013 at 09:01:16AM -0500, Nicolas Pitre wrote:
What about this patch which I think is currently your best option. Note
it would need to use the facilities from asm/opcodes.h to make it endian
agnostic.
diff --git a/arch/arm/ker
On Tue, 12 Nov 2013, Russell King - ARM Linux wrote:
> On Tue, Nov 12, 2013 at 09:01:16AM -0500, Nicolas Pitre wrote:
> > What about this patch which I think is currently your best option. Note
> > it would need to use the facilities from asm/opcodes.h to make it endian
> > agnostic.
> >
> > d
On Tue, Nov 12, 2013 at 09:01:16AM -0500, Nicolas Pitre wrote:
> What about this patch which I think is currently your best option. Note
> it would need to use the facilities from asm/opcodes.h to make it endian
> agnostic.
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> in
On Mon, 11 Nov 2013, Stephen Boyd wrote:
> On 11/09/13 21:03, Nicolas Pitre wrote:
> > Bah. NAK. We are doing runtime patching of the kernel for many
> > many things already. So why not do the same here?
>
> static keys are a form of runtime patching, albeit not as extreme as
> you're suggest
Stephen Boyd writes:
> On 11/09/13 21:03, Nicolas Pitre wrote:
>> Bah. NAK. We are doing runtime patching of the kernel for many
>> many things already. So why not do the same here?
>
> static keys are a form of runtime patching, albeit not as extreme as
> you're suggesting.
>
>>
>> The obvio
On 11/10/13 23:46, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Nov 08, 2013 at 03:00:32PM -0800, Stephen Boyd wrote:
>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>> index bd454b0..38621729 100644
>> --- a/arch/arm/lib/Makefile
>> +++ b/arch/arm/lib/Makefile
>> @@ -15,6 +15,12 @@ l
On 11/09/13 21:03, Nicolas Pitre wrote:
> Bah. NAK. We are doing runtime patching of the kernel for many
> many things already. So why not do the same here?
static keys are a form of runtime patching, albeit not as extreme as
you're suggesting.
>
> The obvious strategy is to simply overwrite
On 11/08/13 22:46, Matt Sealey wrote:
> On Fri, Nov 8, 2013 at 5:00 PM, Stephen Boyd wrote:
>> If we're running on a v7 ARM CPU, detect if the CPU supports the
>> sdiv/udiv instructions and replace the signed and unsigned
>> division library functions with an sdiv/udiv instruction.
>>
>> Running t
Hello,
On Fri, Nov 08, 2013 at 03:00:32PM -0800, Stephen Boyd wrote:
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index bd454b0..38621729 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -15,6 +15,12 @@ lib-y := backtrace.o changebit.o csumipv6
On Fri, 8 Nov 2013, Stephen Boyd wrote:
> If we're running on a v7 ARM CPU, detect if the CPU supports the
> sdiv/udiv instructions and replace the signed and unsigned
> division library functions with an sdiv/udiv instruction.
>
> Running the perf messaging benchmark in pipe mode
>
> $ perf be
Matt Sealey writes:
> BTW has there been any evaluation of the penalty for the extra
> branching, or the performance hit for the ARMv7-without-division
> cases?
The branches themselves probably have minimal overhead. There will
however be code to preserve call-clobbered registers (and move the
On Fri, Nov 8, 2013 at 5:00 PM, Stephen Boyd wrote:
> If we're running on a v7 ARM CPU, detect if the CPU supports the
> sdiv/udiv instructions and replace the signed and unsigned
> division library functions with an sdiv/udiv instruction.
>
> Running the perf messaging benchmark in pipe mode
>
>
If we're running on a v7 ARM CPU, detect if the CPU supports the
sdiv/udiv instructions and replace the signed and unsigned
division library functions with an sdiv/udiv instruction.
Running the perf messaging benchmark in pipe mode
$ perf bench sched messaging -p
shows a modest improvement on m
20 matches
Mail list logo
