All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Matt Mackall <mpm@selenic.com>
Cc: David Miller <davem@davemloft.net>,
	nickpiggin@yahoo.com.au, akpm@linux-foundation.org,
	clameter@sgi.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [QUICKLIST 0/4] Arch independent quicklists V2
Date: Tue, 13 Mar 2007 14:36:11 -0700	[thread overview]
Message-ID: <45F7194B.5080705@goop.org> (raw)
In-Reply-To: <20070313211435.GP10394@waste.org>

Matt Mackall wrote:
> Well you -could- do this:
>
> - reuse a long in struct page as a used map that divides the page up
>   into 32 or 64 segments
> - every time you set a PTE, set the corresponding bit in the mask
> - when we zap, only visit the regions set in the mask
>
> Thus, you avoid visiting most of a PMD page in the sparse case,
> assuming PTEs aren't evenly spread across the PMD.
>
> This might not even be too horrible as the appropriate struct page
> should be in cache with the appropriate bits of the mm already locked,
> etc.
>   

And do the same in pte pages for actual mapped pages?  Or do you think
they would be too densely populated for it to be worthwhile?

    J


WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Matt Mackall <mpm@selenic.com>
Cc: David Miller <davem@davemloft.net>,
	nickpiggin@yahoo.com.au, akpm@linux-foundation.org,
	clameter@sgi.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [QUICKLIST 0/4] Arch independent quicklists V2
Date: Tue, 13 Mar 2007 14:36:11 -0700	[thread overview]
Message-ID: <45F7194B.5080705@goop.org> (raw)
In-Reply-To: <20070313211435.GP10394@waste.org>

Matt Mackall wrote:
> Well you -could- do this:
>
> - reuse a long in struct page as a used map that divides the page up
>   into 32 or 64 segments
> - every time you set a PTE, set the corresponding bit in the mask
> - when we zap, only visit the regions set in the mask
>
> Thus, you avoid visiting most of a PMD page in the sparse case,
> assuming PTEs aren't evenly spread across the PMD.
>
> This might not even be too horrible as the appropriate struct page
> should be in cache with the appropriate bits of the mm already locked,
> etc.
>   

And do the same in pte pages for actual mapped pages?  Or do you think
they would be too densely populated for it to be worthwhile?

    J

--
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:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-03-13 21:36 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13  7:13 [QUICKLIST 0/4] Arch independent quicklists V2 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 1/4] Generic quicklist implementation Christoph Lameter
2007-03-13  9:05   ` Paul Mundt
2007-03-15 20:51     ` Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 2/4] Quicklist support for i386 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 3/4] Quicklist support for x86_64 Christoph Lameter
2007-03-13  7:13 ` [QUICKLIST 4/4] Quicklist support for sparc64 Christoph Lameter
2007-03-13  8:53 ` [QUICKLIST 0/4] Arch independent quicklists V2 Andrew Morton
2007-03-13  8:03   ` Nick Piggin
2007-03-13 11:52     ` Andrew Morton
2007-03-13 11:06       ` Nick Piggin
2007-03-13 11:06         ` Nick Piggin
2007-03-13 12:15         ` Andrew Morton
2007-03-13 12:15           ` Andrew Morton
2007-03-13 11:20           ` Christoph Lameter
2007-03-13 11:20             ` Christoph Lameter
2007-03-13 12:30             ` Andrew Morton
2007-03-13 12:30               ` Andrew Morton
2007-03-15 20:23               ` Christoph Lameter
2007-03-15 20:23                 ` Christoph Lameter
2007-03-13 11:30           ` Nick Piggin
2007-03-13 11:30             ` Nick Piggin
2007-03-13 12:47             ` Andrew Morton
2007-03-13 12:47               ` Andrew Morton
2007-03-13 12:01               ` Nick Piggin
2007-03-13 12:01                 ` Nick Piggin
2007-03-13 13:11                 ` Andrew Morton
2007-03-13 13:11                   ` Andrew Morton
2007-03-13 12:18                   ` Nick Piggin
2007-03-13 12:18                     ` Nick Piggin
2007-03-13 17:30                 ` Jeremy Fitzhardinge
2007-03-13 17:30                   ` Jeremy Fitzhardinge
2007-03-13 20:03                   ` Matt Mackall
2007-03-13 20:03                     ` Matt Mackall
2007-03-13 20:17                     ` Jeremy Fitzhardinge
2007-03-13 20:17                       ` Jeremy Fitzhardinge
2007-03-13 20:21                       ` Matt Mackall
2007-03-13 20:21                         ` Matt Mackall
2007-03-13 21:07                         ` David Miller
2007-03-13 21:07                           ` David Miller, Matt Mackall
2007-03-13 21:14                           ` Matt Mackall
2007-03-13 21:14                             ` Matt Mackall
2007-03-13 21:36                             ` Jeremy Fitzhardinge [this message]
2007-03-13 21:36                               ` Jeremy Fitzhardinge
2007-03-13 21:46                               ` Peter Chubb
2007-03-13 21:46                                 ` Peter Chubb
2007-03-13 21:48                             ` David Miller
2007-03-13 21:48                               ` David Miller, Matt Mackall
2007-03-14  1:12               ` William Lee Irwin III
2007-03-14  1:12                 ` William Lee Irwin III
2007-03-15 23:12                 ` William Lee Irwin III
2007-03-15 23:12                   ` William Lee Irwin III
2007-03-13 23:58       ` Paul Mackerras
2007-03-13 11:17   ` Christoph Lameter
2007-03-13 12:27     ` Andrew Morton
2007-03-15 20:28       ` Christoph Lameter

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=45F7194B.5080705@goop.org \
    --to=jeremy@goop.org \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=nickpiggin@yahoo.com.au \
    /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.