All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.