linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

      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