[lustre-devel] caching in Lustre
quentin.bouget at cea.fr
quentin.bouget at cea.fr
Tue Dec 13 02:02:06 PST 2016
Hi all,
I am currently trying to work out how Lustre behaves when both
"read_cache" and "writethrough_cache" are disabled. What I particularly
want to know is how does writing to the related proc files influence the
cache policy?
To me (and perf_event reports it too on a 2.7 setup), the code always
gets cache pages (using find_or_create_page() in
"lustre/osd-ldiskfs/osd_io.c") even with both cache parameters set to 0.
After that, if caching is disabled, a call to
generic_error_remove_page() is issued on the pages that were allocated.
This functions is described in the kernel sources like this:
*//* * Used to get rid of pages on hardware memory corruption. */ int
generic_error_remove_page(struct adress_space *mapping, struct page
*page) /*
This does not seem to be the "natural" call to use, but anyway, I can
live with that.
What really bothers me is that the behaviour of Lustre from this point
looks exactly the same as if cache was enabled. I can't find a single
branching point that handles things differently: pages are kmapped,
written to/read from, kunmmaped... I am probably missing something, but
I can't figure out what. Could someone please point me in the right
direction?
The functions I find the most relevant to study are:
"lustre/ofd/ofd_io.c":
ofd_preprw() -> ofd_preprw_read() / ofd_preprw_write()
their counterparts:
"lustre/ofd/ofd_io.c":
ofd_commitrw() -> ofd_commitrw_read() / ofd_commitrw_write()
the handlers of the proc files
"/proc/fs/lustre/obdfilter/*/{read,writethrough}_cache_enable":
"lustre/osd-ldiskfs/osd_lproc.c":
ldiskfs_osd_cache_seq_write(), ldiskfs_osd_wcache_seq_write()
and the only places that use the variables set by the proc files (where
generic_error_remove_page() is used):
"lustre/osd-ldiskfs/osd_io.c":
osd_read_prep(), osd_write_prep()
(I suspect I am missing something really important about what
generic_error_remove_page() does)
Regards
Quentin Bouget
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20161213/418a8d6e/attachment.htm>
More information about the lustre-devel
mailing list