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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox