Sorry for the slow response:
The performance of XFS on Linux is not where it should be yet.
We are working on improving the read and write performance numbers
and will have these up when we hit our beta in the next month or two.
We expect to be better than ext2 in some cases and slower in others.
It will depend on the application/data layout/size/...
I'm assuming you were doing standard read/write calls and standard
mmap'ed access. We are about to turn on delay_alloc which will speed
up writing. Also, if you are writing lots of data per file where
the cache gets blown away, we may have direct I/O ready by release. How much
are you reading/writing?
Jim
>
>I ripped out enough of the non-XFS code to get it working on our MediaGX
>machine, I think it might be that etherboot stuff now and not the
>kernel debugger. Hopefully Monday or Tuesday I can put some effort in
>to tracking that down.
>
>Now I have another question...
>
>I'm not sure how much of this is secret and how much isn't but the scene
>looks something like this: We are building an embedded machine that has
>a huge harddrive in it. Our current requirements are to be able to
>stream 3 streams of data at 2.5 MBytes/sec, to writers and one reader.
>
>With Ext2 we can shoulder that load with our MediaGX. We have a test
>harness that measures it. With standard system I/O we can sustain that
>data rate with 13% CPU load. With mapped I/O we can do it with 9% CPU
>load. The drive is tricked out with full UDMA.
>
>So I hacked the XFS kernel up so it would run on the MediaGX and the
>numbers were stunning. With standard I/O it couldn't sustain that data
>rate with our default test settings (we can adjust a few parameters and
>since the 5th and final game of the western conference semis between the
>Detriot DeadWings and the Colorado Avs is on in about an hour I'm going
>to do it another time and not today..) and it used ~70% CPU load, it
>missed the mark by about 30%. With mapped I/O it really couldn't
>sustain that data rate and took ~81% CPU load, it took over twice as
>long as it should.
>
>Our test isn't scientific yet, I just hacked a kernel and ran it. I
>also have tuned anything, but what kinds of performance work is there to
>be done on XFS. I understand that it's still way ahead of release but
>is there any sort of estimate on how it should performance and what
>kinds of CPU use it should take? I would expect XFS to outperform Ext2
>in throughput but will that cost a lot of CPU cycles?
>
>thanks, and have a great weekend.
>
>Ian Nelson
>
>
|