All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: jon ernst <jonernst07@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: difference between xip and o_direct
Date: Thu, 5 Dec 2013 18:51:47 -0500	[thread overview]
Message-ID: <20131205235147.GB9010@thunk.org> (raw)
In-Reply-To: <CAGW2f1FhAGHf3rKozri=nXZNkG2tPQLBgZJvRC09=_MooSQceg@mail.gmail.com>

On Thu, Dec 05, 2013 at 05:17:24PM -0500, jon ernst wrote:
> Hi,
> I am trying to understand difference between xip and o_direct.
> 
> For XIP, document xip.txt says
> "instead of keeping
> data in the page cache, the need to have a page cache copy is eliminated
> completely. With execute-in-place, read&write type operations are performed
> directly from/to the memory backed storage device."

XIP is used when the storage device is already directly addressable
from the CPU.  Most commonly, the file system image located on a PROM,
EPROM, or NOR FLASH.  Normally, we need to copy the executable's text
segment from the HDD or other storage device into the page cache, and
then we map the page from the page cache into the process' page
tables.

But if the storage device is directly conncted to the CPU, then it's a
waste of memory to copy the data from the storage device into the page
cache; instead we can just "execute in place", and just map the memory
address of the read-only EPROM memory (or Flash, etc.) into the
process' page tables.

So XIP only can be used for certain storage devices.

> For O_Direct,
> 
> " File I/O is done directly to/from user-
> space buffers.  " from manual of open(2)
> 
> So, are those 2 trying to do the same thing ? The difference I can
> tell is, XIP option can be used when mounting fs. O_Direct is used in
> open system-call.

O_DIRECT is also trying to bypass the page cache, but for diferrent
reasons.  O_DIRECT is not used for text pages, but it is used for data
buffers which are written to disk.  Normally, and write(2) system
calls copy the data to be written into the page cache, and then later
we write the data from the page cache to the hard drive (or other
storage device).  The reason why we need to do this is because that
way the process doesn't have to make sure the user buffers are
properly aligned, and the process may not want to read and write in
file-system-block-sized-chunks.

However, if the process is willing to adhere to the restrictions
implied by O_DIRECT (see the man page for the open system call), then
read and write calls can bypass the page cache, and the I/O requests
can be sent directly to the hard drive.

So unlike XIP, O_DIRECT can work on any storage device, and it applies
to how data blocks are read and written, where as XIP is used for only
certain storage technologies, and applies only for text pages which
are mapped in read-only so we can execute out of the read-only memory.

Hope this helps,

					- Ted

  reply	other threads:[~2013-12-06  2:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 22:17 difference between xip and o_direct jon ernst
2013-12-05 23:51 ` Theodore Ts'o [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-12-05 22:47 jon ernst

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=20131205235147.GB9010@thunk.org \
    --to=tytso@mit.edu \
    --cc=jonernst07@gmail.com \
    --cc=linux-fsdevel@vger.kernel.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.