On Mon, Feb 2, 2015 at 3:45 PM, Yury Norov wrote:
> Alexey,
>
> Yes, ARM has it's own implementation for subj. If you're interested in
> testing
> my patch on your odroid, try this. (Sorry, I have to attach the patch due to
> restrictions on mail agent at office).
Hi Yury,
(please don't drop
On Wed, Feb 04 2015, Yury wrote:
> On 02.02.2015 13:43, Rasmus Villemoes wrote:
>>> @@ -23,86 +50,22 @@
>>> unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
>>> unsigned long offset)
>>> {
>>> - const unsigned long *p = addr +
On Thu, Feb 05 2015, Yury wrote:
> On 02.02.2015 15:56, Rasmus Villemoes wrote:
>> On Mon, Feb 02 2015, "George Spelvin" wrote:
>>
>>> Rasmus Villemoes wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return _find_next_bit(addr, size, offset, 1);', and
On Wed, Feb 04 2015, Yury yury.no...@gmail.com wrote:
On 02.02.2015 13:43, Rasmus Villemoes wrote:
@@ -23,86 +50,22 @@
unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
unsigned long offset)
{
- const unsigned long *p = addr +
On Thu, Feb 05 2015, Yury yury.no...@gmail.com wrote:
On 02.02.2015 15:56, Rasmus Villemoes wrote:
On Mon, Feb 02 2015, George Spelvin li...@horizon.com wrote:
Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return
On Mon, Feb 2, 2015 at 3:45 PM, Yury Norov yury.no...@gmail.com wrote:
Alexey,
Yes, ARM has it's own implementation for subj. If you're interested in
testing
my patch on your odroid, try this. (Sorry, I have to attach the patch due to
restrictions on mail agent at office).
Hi Yury,
(please
On 02.02.2015 15:56, Rasmus Villemoes wrote:
> On Mon, Feb 02 2015, "George Spelvin" wrote:
>
>> Rasmus Villemoes wrote:
>>> ... and this be part of _find_next_bit? Can find_next_bit not be simply
>>> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
>>> find_next_zero_bit?
On 02.02.2015 06:17, George Spelvin wrote:
> Yury Norov wrote:
>> New implementations takes less space in source file (see diffstat)
>> and in object. For me it's 710 vs 453 bytes of text.
>>
>> Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
>> Performance tests were ran on
On 02.02.2015 13:43, Rasmus Villemoes wrote:
> On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
>
>> From: Yury Norov
>>
>> New implementations takes less space in source file (see diffstat)
>> and in object. For me it's 710 vs 453 bytes of text.
>>
> New version generally looks good. Please
On 02.02.2015 06:17, George Spelvin wrote:
Yury Norov y.no...@samsung.com wrote:
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
Performance tests were ran
On 02.02.2015 13:43, Rasmus Villemoes wrote:
On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
From: Yury Norov y.no...@samsung.com
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
New version generally looks good.
On 02.02.2015 15:56, Rasmus Villemoes wrote:
On Mon, Feb 02 2015, George Spelvin li...@horizon.com wrote:
Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return _find_next_bit(addr, size, offset, 1);', and similarly
On Mon, Feb 02 2015, "George Spelvin" wrote:
> Rasmus Villemoes wrote:
>> ... and this be part of _find_next_bit? Can find_next_bit not be simply
>> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
>> find_next_zero_bit? Btw., passing true and false for the boolean
>>
Rasmus Villemoes wrote:
> ... and this be part of _find_next_bit? Can find_next_bit not be simply
> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
> find_next_zero_bit? Btw., passing true and false for the boolean
> parameter may be a little clearer.
Looking at the generated
On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
> From: Yury Norov
>
> New implementations takes less space in source file (see diffstat)
> and in object. For me it's 710 vs 453 bytes of text.
>
New version generally looks good. Please include a summary of the
changes between the versions
On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
From: Yury Norov y.no...@samsung.com
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
New version generally looks good. Please include a summary of the
changes between the
On Mon, Feb 02 2015, George Spelvin li...@horizon.com wrote:
Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return _find_next_bit(addr, size, offset, 1);', and similarly for
find_next_zero_bit? Btw., passing true and
Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return _find_next_bit(addr, size, offset, 1);', and similarly for
find_next_zero_bit? Btw., passing true and false for the boolean
parameter may be a little clearer.
Yury Norov wrote:
> New implementations takes less space in source file (see diffstat)
> and in object. For me it's 710 vs 453 bytes of text.
>
> Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
> Performance tests were ran on userspace with code like this:
>
> /* addr[] is
Yury Norov y.no...@samsung.com wrote:
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
Performance tests were ran on userspace with code like this:
From: Yury Norov
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
Performance tests were ran on userspace with code like this:
/* addr[] is filled from
From: Yury Norov y.no...@samsung.com
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
Performance tests were ran on userspace with code like this:
/*
22 matches
Mail list logo
