From: Christoph Hellwig <hch@infradead.org>
To: Vladimir Saveliev <vs@namesys.com>
Cc: Andrew Morton <akpm@osdl.org>,
Nikita Danilov <nikita@clusterfs.com>,
linux-mm <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: reiser4 core patches: [Was: [RFC] per thread page reservation patch]
Date: Thu, 27 Jan 2005 11:01:12 +0000 [thread overview]
Message-ID: <20050127110112.GA26283@infradead.org> (raw)
In-Reply-To: <1106671038.4466.81.camel@tribesman.namesys.com>
> So, currently, reiser4 depends on the core patches listed below. Would
> you please look over them and let us know which look reasonable and
> which are to be eliminated.
> reiser4-sb_sync_inodes.patch
> This patch adds new operation (sync_inodes) to struct super_operations.
> This operation allows a filesystem to writeout dirty pages not
> necessarily on per-inode basis. Default implementation of this operation
> is sync_sb_inodes.
ok.
> reiser4-allow-drop_inode-implementation.patch
> This EXPORT_SYMBOL-s inodes_stat, generic_forget_inode, destroy_inode
> and wake_up_inode which are needed to implement drop_inode.
> reiser4 implements function similar to generic_delete_inode to be able
> to truncate inode pages together with metadata destroying in
> reiser4_delete_inode whereas generic_delete_inode first truncates pages
> and then calls foofs_delete_inode.
Not okay. I though I explained you how to do it instead already?
> reiser4-truncate_inode_pages_range.patch
> This patch makes truncate_inode_pages_range from truncate_inode_pages.
> truncate_inode_pages_range can truncate only pages which fall into
> specified range. truncate_inode_pages which trucates all pages starting
> from specified offset is made a one liner which calls
> truncate_inode_pages_range.
Ok.
> reiser4-rcu-barrier.patch
> This patch introduces a new interface - rcu_barrier() which waits until
> all the RCUs queued until this call have been completed.
> This patch is by Dipankar Sarma <dipankar@in.ibm.com>
No idea, but if Dipankar things it's okay it probably is.
> reiser4-reget-page-mapping.patch
> This patch allows to remove page from page cache in foofs_releasepage.
probably ok, Andrew?
> reiser4-radix_tree_lookup_slot.patch
> This patch extents radxi tree API with a function which returns pointer
> to found item within the tree.
Idea is okay, implementation needs work:
__lookup_slot should be called radix_tree_lookup_slot and exported direcly.
radix_tree_lookup should be an inlined wrapper in the header, and kill
the != NULL comparims, it's superflous:
static inline void *radix_tree_lookup(struct radix_tree_root *root,
unsigned long index)
{
void **slot = radix_tree_lookup_slot(root, index);
return slot ? *slot : NULL;
}
> reiser4-export-remove_from_page_cache.patch
Probably okay, but why do you need both remove_from_page_cache
and __remove_from_page_cache?
> reiser4-export-page_cache_readahead.patch
ok
> reiser4-export-pagevec-funcs.patch
ok
> reiser4-export-radix_tree_preload.patch
this one is nasty. not your fault though, but why do we even
have global radix-tree preloads instead of pools. What do you
need it for?
> reiser4-export-find_get_pages.patch
Why don't you use pagevecs instead?
> reiser4-export-generic_sync_sb_inodes.patch
Can't find this one in current -mm
> reiser4-export-inode_lock.patch
> Reiser4 used to manipulate with super block inode lists so it needs
> inode_lock exported.
> We are working now to not need this. But quite many things are based on
> it. Is there any chance to have it included?
No. Modules must not look at inode_lock, it's far too much of an
implementation detail.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
prev parent reply other threads:[~2005-01-27 11:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050103011113.6f6c8f44.akpm@osdl.org>
[not found] ` <20050103114854.GA18408@infradead.org>
[not found] ` <41DC2386.9010701@namesys.com>
[not found] ` <1105019521.7074.79.camel@tribesman.namesys.com>
[not found] ` <20050107144644.GA9606@infradead.org>
2005-01-07 17:16 ` [RFC] per thread page reservation patch Vladimir Saveliev
2005-01-07 18:48 ` Andrew Morton
2005-01-07 20:21 ` Nikita Danilov
2005-01-07 19:05 ` Christoph Hellwig
2005-01-07 19:12 ` Christoph Hellwig
2005-01-07 19:21 ` Robert Love
2005-01-07 20:48 ` Nikita Danilov
2005-01-07 20:54 ` Christoph Hellwig
2005-01-07 21:00 ` Nikita Danilov
2005-01-07 21:07 ` Christoph Hellwig
2005-01-07 19:14 ` Paulo Marques
2005-01-07 19:32 ` Christoph Hellwig
2005-01-07 19:42 ` Andi Kleen
2005-01-07 20:55 ` Nikita Danilov
2005-01-07 21:24 ` Andrew Morton
2005-01-07 21:24 ` Andi Kleen
2005-01-07 22:12 ` Nikita Danilov
2005-01-07 23:03 ` Andrew Morton
2005-01-07 23:17 ` Nikita Danilov
2005-01-07 23:43 ` Andrew Morton
2005-01-08 12:44 ` Nikita Danilov
2005-01-08 13:43 ` Hugh Dickins
2005-01-09 11:35 ` Marcelo Tosatti
2005-01-09 18:16 ` Nikita Danilov
2005-01-25 16:39 ` reiser4 core patches: [Was: [RFC] per thread page reservation patch] Vladimir Saveliev
2005-01-27 10:37 ` Adrian Bunk
2005-01-27 11:01 ` Christoph Hellwig [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=20050127110112.GA26283@infradead.org \
--to=hch@infradead.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nikita@clusterfs.com \
--cc=vs@namesys.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox