Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Learner Study <learner.study@gmail.com>
Cc: fio@vger.kernel.org
Subject: Re: FIO for MIPS
Date: Wed, 2 Sep 2009 10:30:21 +0200	[thread overview]
Message-ID: <20090902083020.GN12579@kernel.dk> (raw)
In-Reply-To: <7efa8a7d0909020124j4be78b7au33774be150f09c7c@mail.gmail.com>


I mean that the one of the big problems with posixaio in Linux is that
it screws up the internal io context IO tracking in the kernel because
it uses a bunch of unrelated threads to actually do the IO. If CLONE_IO
had been used as clone() flag, they would at least share a context and
things would work a lot better.

libaio doesn't have this issue, but it requires O_DIRECT to be async (it
doesn't work with buffered IO).


On Wed, Sep 02 2009, Learner Study wrote:
> Hi Jens:
> 
> Do you mean using CLONE_IO with posixaio would be better than O_DIRECT with
> posixaio?
> 
> Thanks!
> 
> On Tue, Sep 1, 2009 at 11:31 PM, Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > Hi,
> >
> > Yes, if you can live with O_DIRECT, libaio performs a lot better than
> > posixaio. Nobody should use posixaio in their apps if they care just a
> > bit about performance, it just doesn't work very well. Using CLONE_IO
> > would help, but even with that it's still pretty suboptimal.
> >
> >
> > On Tue, Sep 01 2009, Learner Study wrote:
> > > Hi Jens:
> > >
> > > Thanks - it works well.
> > >
> > > I'm using FIO with posixaio ioengine and performance is pretty bad. I'm
> > > trying to get libaio to work  in my MIPS environment. Based on my tests
> > in
> > > previous x86 env, I had seen libaio to give better performance with FIO
> > as
> > > compared to posixaio.
> > >
> > > Again, thanks for your prompt help.
> > >
> > > On Mon, Aug 31, 2009 at 10:38 PM, Jens Axboe <jens.axboe@oracle.com>
> > wrote:
> > >
> > > > On Mon, Aug 31 2009, Learner Study wrote:
> > > > > Hello:
> > > > >
> > > > > I checked README for FIO and apparently it isn't yet supported on
> > MIPS64
> > > > > platform yet (atleast until version 1.30)
> > > > > Does someone have a patch I could use to do this? Any other ideas...
> > > >
> > > > I just checked in the below patch. I haven't checked the memory
> > ordering
> > > > defines yet, not sure if any of the mips cpus are weaker ordered. I'll
> > > > check that later, this should at least get you started.
> > > >
> > > > commit c28b912f77c3dafbdcdcf4def2c8c1f9c127100c
> > > > Author: Jens Axboe <jens.axboe@oracle.com>
> > > > Date:   Tue Sep 1 07:23:57 2009 +0200
> > > >
> > > >    MIPS support
> > > >
> > > >    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
> > > >
> > > > diff --git a/arch/arch-mips.h b/arch/arch-mips.h
> > > > new file mode 100644
> > > > index 0000000..759d3a9
> > > > --- /dev/null
> > > > +++ b/arch/arch-mips.h
> > > > @@ -0,0 +1,25 @@
> > > > +#ifndef ARCH_MIPS64_H
> > > > +#define ARCH_MIPS64_H
> > > > +
> > > > +#define ARCH   (arch_mips)
> > > > +
> > > > +#ifndef __NR_ioprio_set
> > > > +#define __NR_ioprio_set                314
> > > > +#define __NR_ioprio_get                315
> > > > +#endif
> > > > +
> > > > +#ifndef __NR_fadvise64
> > > > +#define __NR_fadvise64         215
> > > > +#endif
> > > > +
> > > > +#ifndef __NR_sys_splice
> > > > +#define __NR_sys_splice                263
> > > > +#define __NR_sys_tee           265
> > > > +#define __NR_sys_vmsplice      266
> > > > +#endif
> > > > +
> > > > +#define read_barrier()         __asm__ __volatile__("": : :"memory")
> > > > +#define write_barrier()                __asm__ __volatile__("": :
> > > > :"memory")
> > > > +#define nop                    __asm__ __volatile__("": : :"memory")
> > > > +
> > > > +#endif
> > > > diff --git a/arch/arch.h b/arch/arch.h
> > > > index 28c6632..87db222 100644
> > > > --- a/arch/arch.h
> > > > +++ b/arch/arch.h
> > > > @@ -31,6 +31,8 @@ enum {
> > > >  #include "arch-sparc64.h"
> > > >  #elif defined(__arm__)
> > > >  #include "arch-arm.h"
> > > > +#elif defined(__mips__) || defined(__mips64__)
> > > > +#include "arch-mips.h"
> > > >  #else
> > > >  #error "Unsupported arch"
> > > >  #endif
> > > >
> > > > --
> > > > Jens Axboe
> > > >
> > > >
> >
> > --
> > Jens Axboe
> >
> >

-- 
Jens Axboe


      reply	other threads:[~2009-09-02  8:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7efa8a7d0908311900o2f0bfbb8t52a8b518782e2bdc@mail.gmail.com>
2009-09-01  5:38 ` FIO for MIPS Jens Axboe
2009-09-01 23:43   ` Learner Study
2009-09-02  6:31     ` Jens Axboe
2009-09-02  8:24       ` Learner Study
2009-09-02  8:30         ` Jens Axboe [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=20090902083020.GN12579@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=fio@vger.kernel.org \
    --cc=learner.study@gmail.com \
    /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