Luck, Tony wrote:
Only a new user would have to pull the whole history ... and for most
uses it is sufficient to just pull the current top of the tree. Linus'
own tree only has a history going back to 2.6.12.-rc2 (when he started
using git).
Someday there might be a server daemon that can batch
>That said, is there any plan to change how this functions in the future
>to solve these problems? I.e. have it not use so much diskspace and
>thus use less bandwith. Am I misunderstanding in assuming that after
>say 1000 commits go into the tree it could end up several megs or gigs
>bigger?
Luck, Tony wrote:
Yeah, I'm facing the same issue. I started playing with git last
night. Apart from disk-space usage, it's very nice, though I really
hope someone puts together a web-interface on top of git soon so we
can seek what changed when and by whom.
Disk space issues? A complete git
On Thu, 21 Apr 2005 10:33:29 -0700 David Mosberger wrote:
| > On Thu, 21 Apr 2005 10:19:28 -0700, "Luck, Tony" <[EMAIL PROTECTED]>
said:
|
| >> I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
| >> Do you know what happened?
|
| Tony> If BitKeeper were still in use, I'd
> On Thu, 21 Apr 2005 10:41:52 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said:
Tony> Disk space issues? A complete git repository of the Linux
Tony> kernel with all changesets back to 2.4.0 takes just over 3G
Tony> ... which is big compared to BK, but 3G of disk only costs
Tony> about
>Yeah, I'm facing the same issue. I started playing with git last
>night. Apart from disk-space usage, it's very nice, though I really
>hope someone puts together a web-interface on top of git soon so we
>can seek what changed when and by whom.
Disk space issues? A complete git repository of
> On Thu, 21 Apr 2005 10:19:28 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said:
>> I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
>> Do you know what happened?
Tony> If BitKeeper were still in use, I'd have dropped that patch
Tony> into my "release" tree and asked Linus
>I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you
>know what happened?
If BitKeeper were still in use, I'd have dropped that patch into my
"release" tree and asked Linus to "pull" ... but it's not, and I was
stalled. I should have a "git" tree up and running in the next
Tony and Andrew,
I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you
know what happened?
--david
> On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius <[EMAIL PROTECTED]>
> said:
Andreas> Hi, The fls() patch from David solves the problem :-))
Andreas>
Hi,
The fls() patch from David solves the problem :-))
Do you have an idea, when it will be in the mainline kernel??
Andreas
Bartlomiej ZOLNIERKIEWICZ wrote:
Hi!
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove
Hi!
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ...
So a simple one-liner changes to picture dramatically.
But why ?!?!?
roundup_pow_of_two() uses fls() and ia64 has buggy
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ...
So a simple one-liner changes to picture dramatically.
But why ?!?!?
Andreas
|
jmerkey wrote:
For 3Ware, you need to chage
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ...
So a simple one-liner changes to picture dramatically.
But why ?!?!?
Andreas
|
jmerkey wrote:
For 3Ware, you need to chage
Hi!
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ...
So a simple one-liner changes to picture dramatically.
But why ?!?!?
roundup_pow_of_two() uses fls() and ia64 has buggy
Hi,
The fls() patch from David solves the problem :-))
Do you have an idea, when it will be in the mainline kernel??
Andreas
Bartlomiej ZOLNIERKIEWICZ wrote:
Hi!
A small update.
Patching mm/filemap.c is not necessary in order to get the improved
performance!
It's sufficient to remove
Tony and Andrew,
I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you
know what happened?
--david
On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius [EMAIL PROTECTED]
said:
Andreas Hi, The fls() patch from David solves the problem :-))
Andreas Do you have an
I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you
know what happened?
If BitKeeper were still in use, I'd have dropped that patch into my
release tree and asked Linus to pull ... but it's not, and I was
stalled. I should have a git tree up and running in the next couple
of
On Thu, 21 Apr 2005 10:19:28 -0700, Luck, Tony [EMAIL PROTECTED] said:
I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
Do you know what happened?
Tony If BitKeeper were still in use, I'd have dropped that patch
Tony into my release tree and asked Linus to pull ... but
Yeah, I'm facing the same issue. I started playing with git last
night. Apart from disk-space usage, it's very nice, though I really
hope someone puts together a web-interface on top of git soon so we
can seek what changed when and by whom.
Disk space issues? A complete git repository of the
On Thu, 21 Apr 2005 10:41:52 -0700, Luck, Tony [EMAIL PROTECTED] said:
Tony Disk space issues? A complete git repository of the Linux
Tony kernel with all changesets back to 2.4.0 takes just over 3G
Tony ... which is big compared to BK, but 3G of disk only costs
Tony about $1 (for IDE
On Thu, 21 Apr 2005 10:33:29 -0700 David Mosberger wrote:
| On Thu, 21 Apr 2005 10:19:28 -0700, Luck, Tony [EMAIL PROTECTED]
said:
|
|I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
|Do you know what happened?
|
| Tony If BitKeeper were still in use, I'd have dropped
Luck, Tony wrote:
Yeah, I'm facing the same issue. I started playing with git last
night. Apart from disk-space usage, it's very nice, though I really
hope someone puts together a web-interface on top of git soon so we
can seek what changed when and by whom.
Disk space issues? A complete git
That said, is there any plan to change how this functions in the future
to solve these problems? I.e. have it not use so much diskspace and
thus use less bandwith. Am I misunderstanding in assuming that after
say 1000 commits go into the tree it could end up several megs or gigs
bigger?
If
Luck, Tony wrote:
SNIP
Only a new user would have to pull the whole history ... and for most
uses it is sufficient to just pull the current top of the tree. Linus'
own tree only has a history going back to 2.6.12.-rc2 (when he started
using git).
Someday there might be a server daemon that can
On Wed, 2005-04-20 at 10:55 -0600, jmerkey wrote:
>
> For 3Ware, you need to chage the queue depths, and you will see
> dramatically improved performance. 3Ware can take requests
> a lot faster than Linux pushes them out. Try changing this instead, you
> won't be going to sleep all the time
Burst is good. There's another window in the SCSI layer that limits to
bursts of 128 sector runs (this seems to be the behavior
on 3Ware). I've never changed this, but increasing the max number of
SCSI requests at this layer may help. The
bursty behavior is good, BTW.
Jeff
Andreas Hirstius
I was curious if your patch would change the write rate because I see
only ~550MB/s (continuous) which is about a factor two away from the
capabilities of the disks.
... and got this behaviour (with and without my other patch):
(with single "dd if=/dev/zero of=testxx bs=65536 count=15 &" or
Just tried it, but the performance problem remains :-(
(actually, why should it change? This part of the code didn't change so
much between 2.6.10-bk6 and -bk7...)
Andreas
jmerkey wrote:
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead, you
won't be going to sleep all the time waiting on the read/write
request queues to get "unstarved".
Hi,
We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD HDD
in a software RAID0 configuration (using md).
With kernel 2.6.11 the read performance on the md is reduced by a factor
of 20 (!!) compared to previous kernels.
The write rate to the md doesn't change!! (it actually
Hi,
We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD HDD
in a software RAID0 configuration (using md).
With kernel 2.6.11 the read performance on the md is reduced by a factor
of 20 (!!) compared to previous kernels.
The write rate to the md doesn't change!! (it actually
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead, you
won't be going to sleep all the time waiting on the read/write
request queues to get unstarved.
Just tried it, but the performance problem remains :-(
(actually, why should it change? This part of the code didn't change so
much between 2.6.10-bk6 and -bk7...)
Andreas
jmerkey wrote:
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware
I was curious if your patch would change the write rate because I see
only ~550MB/s (continuous) which is about a factor two away from the
capabilities of the disks.
... and got this behaviour (with and without my other patch):
(with single dd if=/dev/zero of=testxx bs=65536 count=15 or
Burst is good. There's another window in the SCSI layer that limits to
bursts of 128 sector runs (this seems to be the behavior
on 3Ware). I've never changed this, but increasing the max number of
SCSI requests at this layer may help. The
bursty behavior is good, BTW.
Jeff
Andreas Hirstius
On Wed, 2005-04-20 at 10:55 -0600, jmerkey wrote:
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead, you
won't be going to sleep all the time waiting
36 matches
Mail list logo
