From: Jan Kara <jack@suse.cz>
To: Chinmay V S <cvs268@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Peter Zijlstra <peterz@infradead.org>,
linux-fsdevel@vger.kernel.org, hch@lst.de, akpm@osdl.org
Subject: Re: Query regarding inotify and mmap-ed files
Date: Mon, 1 Jul 2013 17:24:20 +0200 [thread overview]
Message-ID: <20130701152420.GA8022@quack.suse.cz> (raw)
In-Reply-To: <CAK-9PRB=Yr-QL4zghWeO9oiz8Qx_JUUfHonEnJS1xavimjreNw@mail.gmail.com>
On Mon 01-07-13 22:08:28, Chinmay V S wrote:
> > But why can't you use current IN_MODIFY event?
> >
>
> Initially i registered a "catch all" inotify watch on the mmap-ed file
> by calling inotify_add_watch() with IN_ALL_EVENTS in the "reader"
> process. But modifications to the file by mmap-ing it in the "writer"
> process did NOT trigger the inotify watch. Even calling msync() did
> NOT trigger any inotify events.
Ah right. If you wrote the data to the file using write(2), you'd see
IN_MODIFY events.
> (BTW, Is this expected behaviour?? v2.6.37 on ARMCortexA8, rootfs on NAND)
>
> The file was mapped using MAP_SHARED to ensure that no copies were
> made in memory and the changes made by the "writer" process are being
> flushed to the file.
>
> Hence added support for IN_SYNC event in the inotify framework.
> https://gist.github.com/TheCodeArtist/5874669
>
> IMHO, this is a well justified addition to the inotify mechanism.
> Since it simplifies the creation of an event notification framework
> for IPC, is any reason why IN_SYNC should *NOT* be mainlined?
There are more places that can sync a file (e.g. sync_file_range() or it
is disputable whether sync(2) should generate the event or not). Generally
it seems to me that you just need to broadcast an event notification to a
group of processes and the fact that you use inotify is a bit arbitrary.
> PS: Once again, i would really really welcome any suggestions to
> implement a simple high performance notification mechanism for IPC
> using any existing alternatives. Running a "patched" kernel is
> something i would like to avoid.
>
> System requirements:
> a. Single data "writer" process.
> b. Multiple "reader" processes, each to be notified of every update by
> the writer.
> c. Processes "writer" and "readers" NOT related. No per-determined
> order of execution.
> d. Events may NOT be dropped.
Well, you could create eventfd descriptor for each reader in the writer,
pass it to each reader via Unix domain sockets and use that for
notification. Passing of actual data can still be done via mmap. But I
agree that it's likely more code than just using inotify.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
prev parent reply other threads:[~2013-07-01 15:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAK-9PRBG+ZOqcDK+GtsF0pKXksa8MYX7sQT46Y3dFW+Un2bG-A@mail.gmail.com>
2013-06-27 10:19 ` Fwd: Query regarding inotify and mmap-ed files Chinmay V S
2013-06-27 10:47 ` Peter Zijlstra
2013-06-27 14:22 ` Chinmay V S
2013-06-27 20:15 ` Al Viro
2013-06-28 3:46 ` Chinmay V S
2013-07-01 13:37 ` Jan Kara
2013-07-01 14:08 ` Chinmay V S
2013-07-01 15:24 ` Jan Kara [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=20130701152420.GA8022@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@osdl.org \
--cc=cvs268@gmail.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).