Lustre-devel archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom.Wang <Tom.Wang@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Readx issue
Date: Fri, 22 Aug 2008 14:54:14 -0400	[thread overview]
Message-ID: <48AF0B56.3000702@sun.com> (raw)
In-Reply-To: <0C7FCB06-03B0-4EEF-B919-2ED836D0586E@Sun.COM>

Hi, Peter

Sure, actually I added 1 in sanity, but did not compare it with normal 
read. I will do that. Thanks!
Thanks
WangDi
Peter Bojanic wrote:
> Wang Di,
>
> Can you produce some sample benchmarks that show IO performance with 
> and without readx? That would be very helpful to understand the 
> benefits of using the new API.
>
> Bojanic
>
> On 22-Aug-08, at 2:02 AM, Peter Braam wrote:
>
>> Very exciting.   I have cc'd lustre-devel, because this is exciting.
>>
>> Peter
>>
>>
>> On 8/21/08 10:56 PM, "Tom.Wang" <Tom.Wang@Sun.COM> wrote:
>>
>>> Hello,
>>>
>>> Readx/writex code has been done based on HEAD. (ACC-sm has been passed)
>>>
>>> Since the target here is to issue the vector read extents req parallel,
>>> so I chosed to implement that by read-ahead
>>> group io, which is async and parallel. And also by this way, it will 
>>> not
>>> touch other module of lustre.
>>>
>>> In vector read-ahead, each read request will control their 
>>> read-ahead by
>>> itself, instead of by the current read-ahead window, where multi
>>> read-threads(for the same file) use single read ahead window.
>>>
>>> Because current read-ahead
>>>  1)Use a single continuous RA window to control the read ahead.
>>>  2)The read-ahead moves forward according to the global RA window(for
>>> all the read threads of this file), so it tries to favour all the read
>>> threads of the file,
>>>
>>> This algorithm is not very nice for vector read-ahead. because
>>> 1) It is hard to manage the multi discontinuous read-ahead window, for
>>> example add/remove the extents from the window will be very subtle.
>>> 2) It is hard to favour all the vector read-threads(for the file) by 1
>>> single read-ahead window.
>>>
>>> So I let each vector read threads control their read-ahead themselves,
>>> which will make implementation very easy, and it will also not touch
>>> original read-ahead algorithm for non-vector read.  If you disagree
>>> about this, please tell me.
>>>
>>> So all the implementation(readx,writex) actually did not touch other
>>> module at all currently.  I will ask some senior ppl to inspect the
>>> patch. I do not know the further plan with CERN, will they try this
>>> current release or HEAD? If they want try it in current release. Is 
>>> that
>>> ok I could land it in b1_6 or b1_8 after it pass inspection? Please 
>>> advise.
>>>
>>> Thanks
>>> WangDi
>>
>>
>

      reply	other threads:[~2008-08-22 18:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <48AE46F0.9060105@sun.com>
2008-08-22  5:02 ` [Lustre-devel] Readx issue Peter Braam
2008-08-22 17:18   ` Andreas Dilger
2008-08-22 18:44     ` Tom.Wang
2008-08-22 18:50   ` Peter Bojanic
2008-08-22 18:54     ` Tom.Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48AF0B56.3000702@sun.com \
    --to=tom.wang@sun.com \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox