From: Andrew Morton <akpm@digeo.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-mm@kvack.org
Subject: Re: [patch] Buffers pinning inodes in icache forever
Date: Wed, 06 Nov 2002 14:40:07 -0800 [thread overview]
Message-ID: <3DC99A47.6016C6E9@digeo.com> (raw)
In-Reply-To: 200211062159.gA6LxmK23126@sisko.scot.redhat.com
"Stephen C. Tweedie" wrote:
>
> ...
> Doing the refile really isn't hard, either. We expect IO completion
> to be happening in approximately list order on the BUF_LOCKED list, so
> simply doing a refile on any unlocked buffers at the head of that list
> is going to keep it under control in O(1) time per buffer.
>
> With the patch below we've not seen this particular pathology recur.
> Comments?
See IRC for discussion ;) Seems good.
2.5 will have the same problem, and doesn't have the global
buffer list. So doing it per-inode should work. Untested patch
follows. (This approach would work in 2.4 as well?)
--- 25/fs/buffer.c~remove-inode-buffers Wed Nov 6 14:17:36 2002
+++ 25-akpm/fs/buffer.c Wed Nov 6 14:24:58 2002
@@ -870,6 +870,28 @@ void invalidate_inode_buffers(struct ino
}
/*
+ * Remove any clean buffers from the inode's buffer list. This is called
+ * when we're trying to free the inode itself. Those buffers can pin it.
+ */
+void remove_inode_buffers(struct inode *inode)
+{
+ if (inode_has_buffers(inode)) {
+ struct address_space *mapping = inode->i_mapping;
+ struct list_head *list = &mapping->private_list;
+ struct address_space *buffer_mapping = mapping->assoc_mapping;
+
+ spin_lock_irq(&buffer_mapping->i_private_lock);
+ while (!list_empty(list)) {
+ struct buffer_head *bh = BH_ENTRY(list->next);
+ if (buffer_dirty(bh))
+ break;
+ __remove_assoc_queue(bh);
+ }
+ spin_unlock_irq(&buffer_mapping->i_private_lock);
+ }
+}
+
+/*
* Create the appropriate buffers when given a page for data area and
* the size of each buffer.. Use the bh->b_this_page linked list to
* follow the buffers created. Return NULL if unable to create more
--- 25/include/linux/buffer_head.h~remove-inode-buffers Wed Nov 6 14:17:36 2002
+++ 25-akpm/include/linux/buffer_head.h Wed Nov 6 14:17:36 2002
@@ -141,6 +141,7 @@ void buffer_insert_list(spinlock_t *lock
void mark_buffer_dirty_inode(struct buffer_head *bh, struct inode *inode);
int inode_has_buffers(struct inode *);
void invalidate_inode_buffers(struct inode *);
+void remove_inode_buffers(struct inode *inode);
int fsync_buffers_list(spinlock_t *lock, struct list_head *);
int sync_mapping_buffers(struct address_space *mapping);
void unmap_underlying_metadata(struct block_device *bdev, sector_t block);
--- 25/fs/inode.c~remove-inode-buffers Wed Nov 6 14:17:36 2002
+++ 25-akpm/fs/inode.c Wed Nov 6 14:17:36 2002
@@ -371,6 +371,8 @@ static int can_unuse(struct inode *inode
return 0;
if (atomic_read(&inode->i_count))
return 0;
+ if (inode->i_data.nrpages)
+ return 0;
return 1;
}
@@ -399,13 +401,14 @@ static void prune_icache(int nr_to_scan)
inode = list_entry(inode_unused.prev, struct inode, i_list);
- if (!can_unuse(inode)) {
+ if (inode->i_state || atomic_read(&inode->i_count)) {
list_move(&inode->i_list, &inode_unused);
continue;
}
- if (inode->i_data.nrpages) {
+ if (inode_has_buffers(inode) || inode->i_data.nrpages) {
__iget(inode);
spin_unlock(&inode_lock);
+ remove_inode_buffers(inode);
invalidate_inode_pages(&inode->i_data);
iput(inode);
spin_lock(&inode_lock);
@@ -415,8 +418,6 @@ static void prune_icache(int nr_to_scan)
continue; /* wrong inode or list_empty */
if (!can_unuse(inode))
continue;
- if (inode->i_data.nrpages)
- continue;
}
list_del_init(&inode->i_hash);
list_move(&inode->i_list, &freeable);
_
--
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/
next prev parent reply other threads:[~2002-11-06 22:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-06 21:59 [patch] Buffers pinning inodes in icache forever Stephen C. Tweedie
2002-11-06 22:40 ` Andrew Morton [this message]
2002-11-07 2:16 ` Rik van Riel
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=3DC99A47.6016C6E9@digeo.com \
--to=akpm@digeo.com \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.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.