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
prev parent 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 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.