public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

-

      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