All of lore.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Scalable page cache
Date: Mon, 26 Nov 2001 17:29:51 +0000 (UTC)	[thread overview]
Message-ID: <9ttu6f$9ve$1@penguin.transmeta.com> (raw)
In-Reply-To: <87elml4ssx.fsf@fadata.bg> <Pine.LNX.4.33.0111261753480.10763-100000@localhost.localdomain>

In article <Pine.LNX.4.33.0111261753480.10763-100000@localhost.localdomain>,
Ingo Molnar  <mingo@elte.hu> wrote:
>
>it gets rid of the pagecache lock without introducing a tree.
>
>while reducing memory footprint is a goal we want to achieve, the
>pagecache hash is such a critical piece of data structure that we want
>O(1)-type search properties, not a tree. The pagetable hash takes up 0.2%
>of RAM currently. (but we could cut the size of the hash in half i think,
>it's a bit over-sized currently - it has as many entries.)

I actually considered a tree a long time ago, but I was thinking more
along the lines of the page table tree - with the optimization of being
able to perhaps map sub-trees _directly_ into the address space. 

it's a cool idea, especially if done right (ie try to share the
functions between the VM trees and the "page cache tree"), but I was too
lazy to try it out (it's a _lot_ of work to do right).  And I suspect
that it would optimize all the wrong cases, ie on x86 you could mmap
4MB-aligned areas at 4MB offsets with "zero cost", but in real life
that's not a very common situation.

Tree's _do_ have advantages over hashes, though, in having both better
cache locality and better locking locality. 

I don't think a binary tree (even if it is self-balancing) is the proper
format, though.  Binary trees have bad cache characteristics, and as
Ingo points out, with large files (and many performance-critical things
like databases have _huge_ files) you get bad behaviour on lookup with a
binary tree. 

A indexed tree (like the page tables) has much better characteristics,
and can be looked up in O(1), and might be worth looking into. The
locality of a indexed tree means that it's MUCH easier to efficiently
fill in (or get rid of) large contiguous chunks of page cache than it is
with hashes. This can be especially useful for doing swapping, where you
don't have to look up adjacent pages - they're right there, adjacent to
your entry.

Anybody interested?

		Linus

  parent reply	other threads:[~2001-11-26 17:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-26 12:31 [PATCH] Scalable page cache Momchil Velikov
2001-11-26 17:22 ` Ingo Molnar
2001-11-26 17:23   ` Momchil Velikov
2001-11-26 18:16     ` Benjamin LaHaise
2001-11-26 18:42       ` Rik van Riel
2001-11-26 20:29       ` Ingo Molnar
2001-11-26 18:33         ` David S. Miller
2001-11-26 19:29           ` Andrew Morton
2001-11-26 19:35             ` David S. Miller
2001-11-26 18:34         ` Benjamin LaHaise
2001-11-26 20:40       ` Ingo Molnar
2001-11-26 19:19         ` Benjamin LaHaise
2001-11-26 21:00         ` Ingo Molnar
2001-11-26 20:43       ` Daniel Phillips
2001-11-26 19:49     ` Ingo Molnar
2001-11-26 18:08       ` Christoph Hellwig
2001-11-26 20:13         ` Ingo Molnar
2001-11-26 21:09     ` Ingo Molnar
2001-11-26 19:18       ` David S. Miller
2001-11-26 19:45         ` Andrew Morton
2001-11-26 19:57           ` David S. Miller
2001-11-26 20:03             ` Andrew Morton
2001-11-26 20:37             ` Linus Torvalds
2001-11-26 21:02               ` Andrew Morton
2001-11-26 22:23                 ` Linus Torvalds
2001-11-26 22:49                   ` Jeff Garzik
2001-11-26 23:06                     ` Linus Torvalds
2001-11-26 21:10       ` Ingo Molnar
2001-11-26 17:29   ` Linus Torvalds [this message]
2001-11-26 20:03     ` Ingo Molnar
2001-11-26 18:02   ` David S. Miller
2001-11-26 18:11     ` Rik van Riel
2001-11-27  8:07     ` benchmark results: " Anton Blanchard
2001-11-26 18:52   ` [PATCH] " Daniel Phillips

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='9ttu6f$9ve$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.