Hi
I'm noticing quite slower speed of my git rebase commands on my git
tree compared with 2.6.38 kernel.
I've T61 with SSD disc drive, ext4 fs, and by default deadline disk
io scheduler
The counter showing the number of 'rebased' patches on top of master
is going much slower.
When I boot 2.6.38 kernel it's much faster.
Is it a known problem - or do I need to make a bisect ?
Zdenek
Hi,
[ Fixed your empty CC list. ]
On Tue, Apr 12, 2011 at 3:45 PM, Zdenek Kabelac
<[email protected]> wrote:
> I'm noticing quite slower speed of my git rebase commands on my git
> tree compared with 2.6.38 kernel.
> I've ?T61 with SSD disc drive, ext4 fs, and by default deadline disk
> io scheduler
> The counter showing the number of 'rebased' patches on top of master
> is going much slower.
> When I boot 2.6.38 kernel it's much faster.
>
> Is it a known problem - or do I need to make a bisect ?
No, I don't think it's a known problem. Git bisect would be helpful, obviously.
Pekka
On 2011-04-12 14:51, Pekka Enberg wrote:
> Hi,
>
> [ Fixed your empty CC list. ]
>
> On Tue, Apr 12, 2011 at 3:45 PM, Zdenek Kabelac
> <[email protected]> wrote:
>> I'm noticing quite slower speed of my git rebase commands on my git
>> tree compared with 2.6.38 kernel.
>> I've T61 with SSD disc drive, ext4 fs, and by default deadline disk
>> io scheduler
>> The counter showing the number of 'rebased' patches on top of master
>> is going much slower.
>> When I boot 2.6.38 kernel it's much faster.
>>
>> Is it a known problem - or do I need to make a bisect ?
>
> No, I don't think it's a known problem. Git bisect would be helpful,
> obviously.
Definitely, interesting. Bisect would help. I'll try a similar workload
here and see if I see any differences. How big is your rebase, and what
are the runtimes (approximately) on .38 vs .39-rc?
--
Jens Axboe
2011/4/12 Jens Axboe <[email protected]>:
> On 2011-04-12 14:51, Pekka Enberg wrote:
>> Hi,
>>
>> [ Fixed your empty CC list. ]
>>
>> On Tue, Apr 12, 2011 at 3:45 PM, Zdenek Kabelac
>> <[email protected]> wrote:
>>> I'm noticing quite slower speed of my git rebase commands on my git
>>> tree compared with 2.6.38 kernel.
>>> I've ?T61 with SSD disc drive, ext4 fs, and by default deadline disk
>>> io scheduler
>>> The counter showing the number of 'rebased' patches on top of master
>>> is going much slower.
>>> When I boot 2.6.38 kernel it's much faster.
>>>
>>> Is it a known problem - or do I need to make a bisect ?
>>
>> No, I don't think it's a known problem. Git bisect would be helpful,
>> obviously.
>
> Definitely, interesting. Bisect would help. I'll try a similar workload
> here and see if I see any differences. How big is your rebase, and what
> are the runtimes (approximately) on .38 vs .39-rc?
>
I've made just quick build with the small kernel without debug options
enable - and the time is then equal with 2.6.38. So the difference is
probably somewhere in debug build - I assume some debug option
slowed down between 2.6.38 - 2.6.39 significantly.
Zdenek
On 2011-04-12 15:59, Zdenek Kabelac wrote:
> 2011/4/12 Jens Axboe <[email protected]>:
>> On 2011-04-12 14:51, Pekka Enberg wrote:
>>> Hi,
>>>
>>> [ Fixed your empty CC list. ]
>>>
>>> On Tue, Apr 12, 2011 at 3:45 PM, Zdenek Kabelac
>>> <[email protected]> wrote:
>>>> I'm noticing quite slower speed of my git rebase commands on my git
>>>> tree compared with 2.6.38 kernel.
>>>> I've T61 with SSD disc drive, ext4 fs, and by default deadline disk
>>>> io scheduler
>>>> The counter showing the number of 'rebased' patches on top of master
>>>> is going much slower.
>>>> When I boot 2.6.38 kernel it's much faster.
>>>>
>>>> Is it a known problem - or do I need to make a bisect ?
>>>
>>> No, I don't think it's a known problem. Git bisect would be helpful,
>>> obviously.
>>
>> Definitely, interesting. Bisect would help. I'll try a similar workload
>> here and see if I see any differences. How big is your rebase, and what
>> are the runtimes (approximately) on .38 vs .39-rc?
>>
>
> I've made just quick build with the small kernel without debug options
> enable - and the time is then equal with 2.6.38. So the difference is
> probably somewhere in debug build - I assume some debug option
> slowed down between 2.6.38 - 2.6.39 significantly.
Good, so it's down to debug. Thanks for testing.
--
Jens Axboe