All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Zach Brown <zab@zabbo.net>
Cc: paulmck@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, mjbligh@us.ibm.com
Subject: Re: [RFC][PATCH] Interface to invalidate regions of mmaps
Date: Tue, 13 May 2003 16:19:38 -0700	[thread overview]
Message-ID: <20030513161938.1fc00a5e.akpm@digeo.com> (raw)
In-Reply-To: <3EC17BA3.7060403@zabbo.net>

Zach Brown <zab@zabbo.net> wrote:
>
> so what we'd like most is the ability to invalidate a region of the file
> in an efficient go.
> 
> void truncate_inode_pages(struct address_space * mapping, loff_t lstart,
> loff_t end)
> 
> that sort of thing.

That's trivial in 2.5.

>  this might not suck so bad if the page cache was an
> rbtree :)

Or a radix tree.

> but on the other hand, this doesn't solve another problem we have with
> opportunistic lock extents and sparse page cache populations.  Ideally
> we'd like a FS specific pointer in struct page so we can associate pages
> in the cache with a lock,

In 2.5, page->buffers was abstracted out to page->private, and is available
to filesystems for functions such as this.


> but I can't imagine suggesting such a thing
> within earshot of wli. 

wli doesn't have to run your kernel.  If you want to add a pointer to the
pageframe, go add it.  But I'd suggest that you do it with a view to
migrating it to page->private.

When you finally decide to do your development in a development kernel ;)



WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: Zach Brown <zab@zabbo.net>
Cc: paulmck@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, mjbligh@us.ibm.com
Subject: Re: [RFC][PATCH] Interface to invalidate regions of mmaps
Date: Tue, 13 May 2003 16:19:38 -0700	[thread overview]
Message-ID: <20030513161938.1fc00a5e.akpm@digeo.com> (raw)
In-Reply-To: <3EC17BA3.7060403@zabbo.net>

Zach Brown <zab@zabbo.net> wrote:
>
> so what we'd like most is the ability to invalidate a region of the file
> in an efficient go.
> 
> void truncate_inode_pages(struct address_space * mapping, loff_t lstart,
> loff_t end)
> 
> that sort of thing.

That's trivial in 2.5.

>  this might not suck so bad if the page cache was an
> rbtree :)

Or a radix tree.

> but on the other hand, this doesn't solve another problem we have with
> opportunistic lock extents and sparse page cache populations.  Ideally
> we'd like a FS specific pointer in struct page so we can associate pages
> in the cache with a lock,

In 2.5, page->buffers was abstracted out to page->private, and is available
to filesystems for functions such as this.


> but I can't imagine suggesting such a thing
> within earshot of wli. 

wli doesn't have to run your kernel.  If you want to add a pointer to the
pageframe, go add it.  But I'd suggest that you do it with a view to
migrating it to page->private.

When you finally decide to do your development in a development kernel ;)


--
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>

  reply	other threads:[~2003-05-13 23:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 20:36 [RFC][PATCH] Interface to invalidate regions of mmaps Paul E. McKenney
2003-05-13 22:00 ` William Lee Irwin III
2003-05-13 22:00   ` William Lee Irwin III
2003-05-13 22:21 ` Andrew Morton
2003-05-13 22:21   ` Andrew Morton
2003-05-13 22:43   ` Paul E. McKenney
2003-05-13 22:43     ` Paul E. McKenney
2003-05-13 23:11   ` Zach Brown
2003-05-13 23:19     ` Andrew Morton [this message]
2003-05-13 23:19       ` Andrew Morton
2003-05-13 23:57       ` Zach Brown
2003-05-13 23:26     ` William Lee Irwin III
2003-05-13 23:26       ` William Lee Irwin III

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=20030513161938.1fc00a5e.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mjbligh@us.ibm.com \
    --cc=paulmck@us.ibm.com \
    --cc=zab@zabbo.net \
    /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.