From: Fino Meng <fino.meng@linux.intel.com>
To: "孙世龙 sunshilong" <sunshilong369@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: Is it possible to implement a real-time API to read the files on the disk?
Date: Thu, 7 Jan 2021 10:28:44 +0800 [thread overview]
Message-ID: <20210107022843.GA32446@linux.intel.com> (raw)
In-Reply-To: <CAAvDm6bxvLaeRYvTpQM9CgewnK5qRrpV8ExQSuJ72d3axfcYRA@mail.gmail.com>
On Thu, Jan 07, 2021 at 10:03:06AM +0800, 孙世龙 sunshilong wrote:
> >depends on your use case, maybe possible to add a raw disk, only used by
> >the time critical code?
> It seems a good solution.
> It's possible to add a raw disk.
> One more question, does it could guarantee the read operation achieve a
> real-time performance by this method(i.e occupying another disk)?
> Is there still some problem that I should be aware of?
>
raw disk is not shared, then should not mount it.
the drivers of file system and harddisk belongs to non-realtime vanilla
Linux. Choose a fastest disk (PCIE NVMe disk?), then need to implement a
RTDM driver for it, that's quite a lot of work,
those raised in my mind by far,
BR/fino
> On Wed, Jan 6, 2021 at 8:05 AM Fino Meng <fino.meng@linux.intel.com> wrote:
> >
> > On Mon, Jan 04, 2021 at 07:58:53PM +0800, 孙世龙 sunshilong via Xenomai wrote:
> > > Is it possible to implement a real-time API to read the files on the disk?
> > >
> > > As far as I know, there is no such an interface now, but is it
> > > possible to achieve this goal?
> > >
> > > I would be grateful to have some help with this question.
> > >
> > > Best Regards
> > > Sunshilong
> > >
> >
> > my first thinking, disks are heavily shared resources in a general OS, if
> > realtime API occupy it for a long time, non-realtime thread all have to
> > wait.
> >
> > read a file is too much slow compare a realtime thread's latency/jitter
> > scope (< 20us)
> >
> > depends on your use case, maybe possible to add a raw disk, only used by
> > the time critical code?
> >
> > BR/fino
next prev parent reply other threads:[~2021-01-07 2:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 11:58 Is it possible to implement a real-time API to read the files on the disk? 孙世龙 sunshilong
2021-01-04 13:22 ` Julien Blanc
2021-01-06 0:04 ` Fino Meng
2021-01-07 2:03 ` 孙世龙 sunshilong
2021-01-07 2:28 ` Fino Meng [this message]
2021-01-07 11:14 ` Wolfgang Denk
2021-01-07 12:12 ` 孙世龙 sunshilong
2021-01-14 16:55 ` Wolfgang Denk
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=20210107022843.GA32446@linux.intel.com \
--to=fino.meng@linux.intel.com \
--cc=sunshilong369@gmail.com \
--cc=xenomai@xenomai.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.