concurrent direct IO write in xfs

[Zheng Da]

Helllo

On Fri, Jan 20, 2012 at 3:53 AM, Linda Walsh <xfs at tlinx.org> wrote:

>
>
> Zheng Da wrote:
>
>>
>> I create a file of 4GB in XFS (the ramdisk has 5GB of space). My test
>> program overwrites 4G of data to the file
>>
> ----
>        It sounds like you are asking why multiple threads don't
> move memory from one point to another point in memory at a faster rate
> than one thread alone.
>
> I.e. if you had 2 processes doing an assembly instruction, memmov to move
> a chunk of memory from 1 area to another, would you expect to do the move
> any faster if you had 2 processors doing the move vs. 1??
>
Yes. Actually, for reading, using multiple threads is faster than a single
thread.
If you try simple memory copy with memcpy in the C library, the overall
throughput will still increase if you use multiple processors.

>
> I think the limiting factor (unless you have a slow processor and some
> REALLY fast memory, but stock x86-64 parts, today have memory running about
> 2-4 times slower than the processor -- so the memory is usually the
> bottleneck.
>
Memory bandwidth will eventually become a bottleneck, but it can still
scale for a small number of processors.

>
> Two processes wouldn't do it any faster, and might actually do it slower
> due to
> resource contention issues -- I would *think*... but I really don't know
> the
> details of how writing from mem2mem and having the target be in the format
> of
> and xfs file system, would cause cpu-bound delays that would be
> significant to
> change the fact that m2m operations are usually mem-bandwidth limited...?
>
> (I don't know the answers, just clarifying what you are asking)...
>
> Da
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20120120/8b1b98fc/attachment.htm>