From: Andrew Morton <akpm@zip.com.au>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [brokenpatch] page accounting
Date: Thu, 11 Apr 2002 11:04:32 -0700 [thread overview]
Message-ID: <3CB5D030.D98A4626@zip.com.au> (raw)
In-Reply-To: <3CB41BA7.DAC3A785@zip.com.au> <3CB5A82B.80C942A0@in.ibm.com>
Suparna Bhattacharya wrote:
>
> > +#define PG_slab 8 /* kill me if needed: slab debug */
>
> A little plea for mercy for this tiny bit :)
Sure, I'll update the comment.
Things are getting a *little* squeezy in the page->flags
department. The zone takes eight, and of the remaining
24, I'm showing 18 used up. A couple of these can be
recycled easily. I added two to support delayed allocate:
PG_disk_reserved: page has a disk-reservation
PG_space_reclaim: icky hack to avoid deadlocking when
writeback is forced to collapse outstanding
reservations.
A number of the reasons for delalloc are going away now;
we'll be able to do multipage bio-based writeback and
readahead for the map-at-prepare_write buffer-based
filesystems. We'll see.
Updated patchset is at
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.8-pre3/
It hasn't quite recovered from the changed buffer/page
relationship yet - a heavy dbench run on 1k blocksize ext2
dies after half an hour over a page which didn't come unlocked.
- Went back to open-coded per-CPU page accumulators. I
stared at the assembly for some time and it looked OK,
so I'm not sure what went wrong with the `percpu' version.
I'll have another shot later.
- Split fs/fs-writeback.c out from fs/inode.c. These are
all the functions related to sending bulk file data to
storage. fs/inode.c contains the inode writeback code,
the hashing, all the other stuff involved with manipulating
the state of in-core inodes.
I think this is a reasonable splitup - it makes the diff
more readable too...
- include/linux/writeback.h is for communication between
fs/fs-writeback.c, mm/page-writeback.c and fs/inode.c
- Lots more changes to fs/buffer.c; many of them pointless
cleanups and shuffling functions around and documenting
stuff.
- Documenting the VM/fs locking ordering rules, slowly.
- The locking between __set_page_dirty_buffers(),
try_to_free_buffers() and the functions which attach
buffers to pages is coming together. This exclusion
is needed to preserve the buffer-page relationship
which has been proposed.
It would be a ton easier and cleaner if set_page_dirty
was called under the page lock, but that's rather hard
to arrange. Maybe that would be a better approach.
- We need to talk wli into doing a hashed wakeup for the
buffer layer. Then buffer_head will be:
struct buffer_head {
sector_t b_blocknr; /* block number */
unsigned short b_size; /* block size */
kdev_t b_dev; /* device (B_FREE = free) */
struct block_device *b_bdev;
atomic_t b_count; /* users using this block */
unsigned long b_state; /* buffer state bitmap (see above) */
struct buffer_head *b_this_page;/* circular list of buffers in one page */
char * b_data; /* pointer to data block */
struct page *b_page; /* the page this bh is mapped to */
void (*b_end_io)(struct buffer_head *bh, int uptodate); /* I/O completion */
void *b_private; /* reserved for b_end_io */
struct list_head b_inode_buffers; /* doubly linked list of inode dirty buffers */
};
I suspect we can also remove b_dev, maybe b_size, conceivably
b_data.
-
prev parent reply other threads:[~2002-04-11 19:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-10 11:01 [brokenpatch] page accounting Andrew Morton
2002-04-10 12:56 ` Rusty Russell
2002-04-11 15:13 ` Suparna Bhattacharya
2002-04-11 18:04 ` Andrew Morton [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=3CB5D030.D98A4626@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=suparna@in.ibm.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.