* Yury Norov wrote:
> On Tue, May 16, 2017 at 10:30:42AM +0200, Ingo Molnar wrote:
> >
> > * Yury Norov wrote:
> >
> > > I collected about 700 results in dmesg, and took 600 fastest.
> > > For the vanilla kernel, the average value is 368, and for patched
> > > kernel it is 388. It's 5% slower
On Tue, May 16, 2017 at 10:30:42AM +0200, Ingo Molnar wrote:
>
> * Yury Norov wrote:
>
> > I collected about 700 results in dmesg, and took 600 fastest.
> > For the vanilla kernel, the average value is 368, and for patched
> > kernel it is 388. It's 5% slower. But the standard deviation is
> >
* Yury Norov wrote:
> I collected about 700 results in dmesg, and took 600 fastest.
> For the vanilla kernel, the average value is 368, and for patched
> kernel it is 388. It's 5% slower. But the standard deviation is
> really big for both series' - 131 and 106 cycles respectively, which
> is ~
On Mon, May 15, 2017 at 10:58 PM, Yury Norov wrote:
> On Mon, May 15, 2017 at 10:31:17PM +0200, Arnd Bergmann wrote:
>> On Mon, May 15, 2017 at 6:17 PM, Yury Norov
>> wrote:
>>
> Yes, something like this. But size is not the multiple of BITS_PER_LONG in
> general. This should work better:
>
>
On Mon, May 15, 2017 at 10:31:17PM +0200, Arnd Bergmann wrote:
> On Mon, May 15, 2017 at 6:17 PM, Yury Norov wrote:
> > On Mon, May 15, 2017 at 06:06:18PM +0200, Arnd Bergmann wrote:
> >> On Mon, May 15, 2017 at 5:47 PM, Yury Norov
> >> wrote:
> >> > On Sun, May 14, 2017 at 08:09:17PM +0200, Ing
On Mon, May 15, 2017 at 6:17 PM, Yury Norov wrote:
> On Mon, May 15, 2017 at 06:06:18PM +0200, Arnd Bergmann wrote:
>> On Mon, May 15, 2017 at 5:47 PM, Yury Norov
>> wrote:
>> > On Sun, May 14, 2017 at 08:09:17PM +0200, Ingo Molnar wrote:
>> >
>> > I also think that sched_find_first_bit() may be
On Mon, May 15, 2017 at 06:06:18PM +0200, Arnd Bergmann wrote:
> On Mon, May 15, 2017 at 5:47 PM, Yury Norov wrote:
> > On Sun, May 14, 2017 at 08:09:17PM +0200, Ingo Molnar wrote:
> >>
> >> * Yury Norov wrote:
> >>
> >> > sched_find_first_bit() is in fact the unrolled version of
> >> > find_firs
On Mon, May 15, 2017 at 5:47 PM, Yury Norov wrote:
> On Sun, May 14, 2017 at 08:09:17PM +0200, Ingo Molnar wrote:
>>
>> * Yury Norov wrote:
>>
>> > sched_find_first_bit() is in fact the unrolled version of
>> > find_first_bit(), which is theoretically faster in some cases.
>> > But in the kernel
On Sun, May 14, 2017 at 08:09:17PM +0200, Ingo Molnar wrote:
>
> * Yury Norov wrote:
>
> > sched_find_first_bit() is in fact the unrolled version of
> > find_first_bit(), which is theoretically faster in some cases.
> > But in the kernel it is called only in couple places in
> > kernel/sched/rt
On Sat, May 13, 2017 at 3:01 AM, Yury Norov wrote:
> include/asm-generic/bitops/sched.h as it declares only this
> function. Alpha has it's own implementation, very similar to
> generic one, so it is also removed.
Nice consolidation, I see that every architecture once had a copy of
this functio
* Yury Norov wrote:
> sched_find_first_bit() is in fact the unrolled version of
> find_first_bit(), which is theoretically faster in some cases.
> But in the kernel it is called only in couple places in
> kernel/sched/rt.c, and both of them are not looking like hot
> paths [...]
They are in te
sched_find_first_bit() is in fact the unrolled version of
find_first_bit(), which is theoretically faster in some cases.
But in the kernel it is called only in couple places in
kernel/sched/rt.c, and both of them are not looking like hot
paths that will doubtly achieve measurable benefit from usin
12 matches
Mail list logo
