From: mel@skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Nick Piggin <nickpiggin@yahoo.com.au>, Andi Kleen <ak@suse.de>,
Paul Jackson <pj@sgi.com>, Dave Chinner <dgc@sgi.com>
Subject: Re: [RFC 7/8] Enhance ramfs to support higher order pages
Date: Fri, 20 Apr 2007 14:42:27 +0100 [thread overview]
Message-ID: <20070420134226.GA16878@skynet.ie> (raw)
In-Reply-To: <20070419163540.11948.51549.sendpatchset@schroedinger.engr.sgi.com>
On (19/04/07 09:35), Christoph Lameter didst pronounce:
> Variable Order Page Cache: Add support to ramfs
>
> The simplest file system to use is ramfs. Add a mount parameter that
> specifies the page order of the pages that ramfs should use. If the
> order is greater than zero then disable mmap functionality.
>
> This could be removed if the VM would be changes to support faulting
> higher order pages but for now we are content with buffered I/O on higher
> order pages.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> ---
> fs/ramfs/file-mmu.c | 11 +++++++++++
> fs/ramfs/inode.c | 15 ++++++++++++---
> include/linux/ramfs.h | 1 +
> 3 files changed, 24 insertions(+), 3 deletions(-)
>
> Index: linux-2.6.21-rc7/fs/ramfs/file-mmu.c
> ===================================================================
> --- linux-2.6.21-rc7.orig/fs/ramfs/file-mmu.c 2007-04-18 21:46:38.000000000 -0700
> +++ linux-2.6.21-rc7/fs/ramfs/file-mmu.c 2007-04-18 22:02:03.000000000 -0700
> @@ -45,6 +45,17 @@ const struct file_operations ramfs_file_
> .llseek = generic_file_llseek,
> };
>
> +/* Higher order mappings do not support mmmap */
> +const struct file_operations ramfs_file_higher_order_operations = {
> + .read = do_sync_read,
> + .aio_read = generic_file_aio_read,
> + .write = do_sync_write,
> + .aio_write = generic_file_aio_write,
> + .fsync = simple_sync_file,
> + .sendfile = generic_file_sendfile,
> + .llseek = generic_file_llseek,
> +};
> +
> const struct inode_operations ramfs_file_inode_operations = {
> .getattr = simple_getattr,
> };
> Index: linux-2.6.21-rc7/fs/ramfs/inode.c
> ===================================================================
> --- linux-2.6.21-rc7.orig/fs/ramfs/inode.c 2007-04-18 21:46:38.000000000 -0700
> +++ linux-2.6.21-rc7/fs/ramfs/inode.c 2007-04-18 22:02:03.000000000 -0700
> @@ -61,6 +61,7 @@ struct inode *ramfs_get_inode(struct sup
> inode->i_blocks = 0;
> inode->i_mapping->a_ops = &ramfs_aops;
> inode->i_mapping->backing_dev_info = &ramfs_backing_dev_info;
> + inode->i_mapping->order = sb->s_blocksize_bits - PAGE_CACHE_SHIFT;
> inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> switch (mode & S_IFMT) {
> default:
> @@ -68,7 +69,10 @@ struct inode *ramfs_get_inode(struct sup
> break;
> case S_IFREG:
> inode->i_op = &ramfs_file_inode_operations;
> - inode->i_fop = &ramfs_file_operations;
> + if (inode->i_mapping->order)
> + inode->i_fop = &ramfs_file_higher_order_operations;
> + else
> + inode->i_fop = &ramfs_file_operations;
So the difference here appears to be that specifying an order means you
can't mmap(). right?
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based filesystem instead of two.
> break;
> case S_IFDIR:
> inode->i_op = &ramfs_dir_inode_operations;
> @@ -164,10 +168,15 @@ static int ramfs_fill_super(struct super
> {
> struct inode * inode;
> struct dentry * root;
> + int order = 0;
> + char *options = data;
> +
> + if (options && *options)
> + order = simple_strtoul(options, NULL, 10);
>
Not the nicest option there but no harm for the moment.
> sb->s_maxbytes = MAX_LFS_FILESIZE;
> - sb->s_blocksize = PAGE_CACHE_SIZE;
> - sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
> + sb->s_blocksize = PAGE_CACHE_SIZE << order;
> + sb->s_blocksize_bits = order + PAGE_CACHE_SHIFT;
> sb->s_magic = RAMFS_MAGIC;
> sb->s_op = &ramfs_ops;
> sb->s_time_gran = 1;
> Index: linux-2.6.21-rc7/include/linux/ramfs.h
> ===================================================================
> --- linux-2.6.21-rc7.orig/include/linux/ramfs.h 2007-04-18 21:46:38.000000000 -0700
> +++ linux-2.6.21-rc7/include/linux/ramfs.h 2007-04-18 22:02:03.000000000 -0700
> @@ -16,6 +16,7 @@ extern int ramfs_nommu_mmap(struct file
> #endif
>
> extern const struct file_operations ramfs_file_operations;
> +extern const struct file_operations ramfs_file_higher_order_operations;
> extern struct vm_operations_struct generic_file_vm_ops;
> extern int __init init_rootfs(void);
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
next prev parent reply other threads:[~2007-04-20 13:42 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 16:35 [RFC 0/8] Variable Order Page Cache Christoph Lameter
2007-04-19 16:35 ` [RFC 1/8] Add order field to address_space struct Christoph Lameter
2007-04-19 16:35 ` [RFC 2/8] Basic allocation for higher order page cache pages Christoph Lameter
2007-04-20 10:55 ` Mel Gorman
2007-04-19 16:35 ` [RFC 3/8] Flushing and zeroing " Christoph Lameter
2007-04-20 11:02 ` Mel Gorman
2007-04-20 16:15 ` Christoph Lameter
2007-04-20 16:51 ` William Lee Irwin III
2007-04-19 16:35 ` [RFC 4/8] Enhance fallback functions in libs to support higher order pages Christoph Lameter
2007-04-19 18:48 ` Adam Litke
2007-04-19 19:10 ` Christoph Lameter
2007-04-19 22:50 ` David Chinner
2007-04-20 1:15 ` Christoph Lameter
2007-04-20 8:21 ` Jens Axboe
2007-04-20 16:01 ` Christoph Lameter
2007-04-20 16:51 ` Jens Axboe
2007-04-20 11:05 ` Mel Gorman
2007-04-20 18:50 ` Dave Kleikamp
2007-04-20 19:10 ` Christoph Lameter
2007-04-20 19:27 ` Dave Kleikamp
2007-04-24 23:00 ` Matt Mackall
2007-04-19 16:35 ` [RFC 5/8] Enhance generic_read/write " Christoph Lameter
2007-04-19 16:35 ` [RFC 6/8] Account for pages in the page cache in terms of base pages Christoph Lameter
2007-04-19 17:45 ` Nish Aravamudan
2007-04-19 17:52 ` Christoph Lameter
2007-04-19 17:54 ` Avi Kivity
2007-04-19 16:35 ` [RFC 7/8] Enhance ramfs to support higher order pages Christoph Lameter
2007-04-20 13:42 ` Mel Gorman [this message]
2007-04-20 14:47 ` William Lee Irwin III
2007-04-20 16:30 ` Christoph Lameter
2007-04-20 17:11 ` William Lee Irwin III
2007-04-20 17:15 ` Christoph Lameter
2007-04-20 17:19 ` William Lee Irwin III
2007-04-20 17:57 ` Christoph Lameter
2007-04-20 19:21 ` William Lee Irwin III
2007-04-20 17:59 ` Christoph Lameter
2007-04-20 18:01 ` Christoph Lameter
2007-04-20 18:02 ` Christoph Lameter
2007-04-20 16:20 ` Christoph Lameter
2007-04-19 16:35 ` [RFC 8/8] Add some debug output Christoph Lameter
2007-04-19 19:09 ` [RFC 0/8] Variable Order Page Cache Badari Pulavarty
2007-04-19 19:12 ` Christoph Lameter
2007-04-19 19:11 ` Andi Kleen
2007-04-19 19:15 ` Christoph Lameter
2007-04-20 14:37 ` Mel Gorman
2007-04-19 22:42 ` David Chinner
2007-04-20 1:14 ` Christoph Lameter
2007-04-20 6:32 ` Jens Axboe
2007-04-20 7:48 ` David Chinner
2007-04-21 22:18 ` Andrew Morton
2007-04-19 23:58 ` Maxim Levitsky
2007-04-20 1:15 ` Christoph Lameter
2007-04-20 4:47 ` William Lee Irwin III
2007-04-20 5:27 ` Christoph Lameter
2007-04-20 6:22 ` William Lee Irwin III
2007-04-20 8:42 ` David Chinner
2007-04-20 14:14 ` Mel Gorman
2007-04-20 16:23 ` Christoph Lameter
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=20070420134226.GA16878@skynet.ie \
--to=mel@skynet.ie \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
/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.