From: miguel@mtelleria.com (Miguel Telleria de Esteban)
To: kernelnewbies@lists.kernelnewbies.org
Subject: buffer page concepts in the page cache
Date: Tue, 25 Jan 2011 13:56:54 +0100 [thread overview]
Message-ID: <1295960214.4d3ec896e8005@imp.online.net> (raw)
Dear all,
CONTEXT
I am spending the last weeks learning how the kernel executes disk I/O
writes and reads from the userland read() to the hard disk drive. I
want to see (and understand) the WHOLE PICTURE regarding the VFS,
block I/O layer and page cache.
To do this, I am following as a base guide Bovet and Cesati UTLK 3rd
edition [1] (chapters 12-16 so far) and the new edition of Robert
Love's Linux Kernel Development[2] (chapters 13-16). A lot of reading
so far that I still need to slowly digest.
For the moment, I have not dived yet into the details of "page frame
reclaiming", "swap memory" and "filesystem implementations" areas. My
knowledge about memory allocation (slab allocator) is also limited.
[1] Understanding The Linux Kernel 3rd Edition, O'Reilly
[2] Linux Kernel Development 3rd Edition Addison Wesley
MY QUESTIONS
1. What do we understand by "buffer pages"?
2. Is the whole page cache content (i.e. the radix tree in the
address_space of the different inodes) organized as buffer pages?
3. What is the functional difference between "block device buffer
pages" (stored in the address_space of the master bdev inode) and
the "file buffer pages" stored in the address_space of a file
inode? [ UTLK, page 614 ]
Maybe I am missing an important point of course...
MY INTERPRETATION (please correct me if I am wrong)
Q1 What is a "buffer page"?
A "buffer page" is a "struct page" data describing a page allocated to
hold one or more i/o blocks from disk.
As such, the "private" field points to a single circular list of
"buffer_heads" each describing the mapping between the i/o blocks in
memory (b_data field) and the i/o blocks on disk (b_size,
b_blocknr...).
The buffer_head structures themselves are stored outside of the page
as shown in UTLK Fig 15.2.
---
Q2 Is the whole page cache content organized as buffer pages?
YES, there is no other way to link memory-mapped disk i/o data to the
struct page pointed by address_space radix-tree entries.
---
Q3 block device buffer_pages vs file buffer_pages
This I really don't understand. From what UTLK page 614 says:
* File buffer_pages ONLY refer to non-contiguous (on disk layout) file
contents.
* blockdev buffer_pages refer to single-block or continuous (on disk
layout) portions of block.
My question is: what happens with non-fragmented medium size files
that do not contain "disk holes" or non-adjancent block submissions?
Thanks in advance for your attention,
Miguel
next reply other threads:[~2011-01-25 12:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-25 12:56 Miguel Telleria de Esteban [this message]
2011-01-25 18:19 ` buffer page concepts in the page cache Mulyadi Santosa
2011-01-25 19:10 ` Miguel Telleria de Esteban
2011-01-26 4:19 ` Mulyadi Santosa
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=1295960214.4d3ec896e8005@imp.online.net \
--to=miguel@mtelleria.com \
--cc=kernelnewbies@lists.kernelnewbies.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.