On Tue, Mar 13, 2007 at 06:12:44PM -0700, William Lee Irwin III wrote:
> There are furthermore distinctions to make between fork() and execve().
> fork() stomps over the entire process address space copying pagetables
> en masse. After execve() a process incrementally faults in PTE's one at
> a
On Tue, 13 Mar 2007, Andrew Morton wrote:
> > 1. We need to support other states of pages other than zeroed.
>
> What does this mean?
pgd are not completely zeroed. They contain mappings that are always
present. Thus the state is not a zeroed state.
> > 2. Prezeroing does not make much sense
On Tue, 13 Mar 2007, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 04:20:48 -0700 (PDT) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> > On Tue, 13 Mar 2007, Andrew Morton wrote:
> >
> > > Yeah, prezeroing in idle is probably pointless. But I'm not aware of
> > > anyone having tried it
On Tue, 13 Mar 2007, Andrew Morton wrote:
On Tue, 13 Mar 2007 04:20:48 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 13 Mar 2007, Andrew Morton wrote:
Yeah, prezeroing in idle is probably pointless. But I'm not aware of
anyone having tried it properly...
Ok,
On Tue, 13 Mar 2007, Andrew Morton wrote:
1. We need to support other states of pages other than zeroed.
What does this mean?
pgd are not completely zeroed. They contain mappings that are always
present. Thus the state is not a zeroed state.
2. Prezeroing does not make much sense if a
On Tue, Mar 13, 2007 at 06:12:44PM -0700, William Lee Irwin III wrote:
There are furthermore distinctions to make between fork() and execve().
fork() stomps over the entire process address space copying pagetables
en masse. After execve() a process incrementally faults in PTE's one at
a time.
On Tue, Mar 13, 2007 at 04:47:56AM -0800, Andrew Morton wrote:
> I'm trying to remember why we ever would have needed to zero out the
> pagetable pages if we're taking down the whole mm? Maybe it's
> because "oh, the arch wants to put this page into a quicklist to
> recycle it", which is all
Andrew Morton writes:
> Plus, we can get in a situation where take a cache-cold, known-zero page
> from the pte quicklist when there is a cache-hot, non-zero page sitting in
> the page allocator. I suspect that zeroing the cache-hot page would take a
> similar amount of time to a single miss
> "Jeremy" == Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Jeremy> And do the same in pte pages for actual mapped pages? Or do
Jeremy> you think they would be too densely populated for it to be
Jeremy> worthwhile?
We've been doing some measurements on how densely clumped ptes are.
On
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 16:14:35 -0500
> 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
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
On Tue, Mar 13, 2007 at 02:07:22PM -0700, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 13 Mar 2007 15:21:25 -0500
>
> > Because the fan-out is large, the bulk of the work is bringing the last
> > layer of the tree into cache to find all the pages in the address
> >
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 15:21:25 -0500
> Because the fan-out is large, the bulk of the work is bringing the last
> layer of the tree into cache to find all the pages in the address
> space. And there's really no way around that.
That's right.
And I will
On Tue, Mar 13, 2007 at 01:17:00PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
> >
> >> Nick Piggin wrote:
> >>
> >>> However we still have to visit those to-be-unmapped parts of the page
> >>> table,
>
On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
> Nick Piggin wrote:
> > However we still have to visit those to-be-unmapped parts of the page
> > table,
> > to find the pages and free them. So we still at least need to bring it
> > into
> > cache for the read... at which
Matt Mackall wrote:
> On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> However we still have to visit those to-be-unmapped parts of the page
>>> table,
>>> to find the pages and free them. So we still at least need to bring it
>>> into
>>>
Nick Piggin wrote:
> However we still have to visit those to-be-unmapped parts of the page
> table,
> to find the pages and free them. So we still at least need to bring it
> into
> cache for the read... at which point, the store probably isn't a big
> burden.
Why not try to find a place to stash
Andrew Morton wrote:
On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
It would be interesting to look at a) leave the page full of random garbage
if we're releasing the whole mm and b) return it straight to the page allocator.
Well we have the
> On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>We don't actually have to zap_pte_range the entire page table in
> >>order to free it (IIRC we used to have to,
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
We don't actually have to zap_pte_range the entire page table in
order to free it (IIRC we used to have to, before the 4lpt patches).
I'm trying to remember why we ever would have needed to zero out
> On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> We don't actually have to zap_pte_range the entire page table in
> order to free it (IIRC we used to have to, before the 4lpt patches).
I'm trying to remember why we ever would have needed to zero out the pagetable
> On Tue, 13 Mar 2007 04:20:48 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 13 Mar 2007, Andrew Morton wrote:
>
> > Yeah, prezeroing in idle is probably pointless. But I'm not aware of
> > anyone having tried it properly...
>
> Ok, then what did I do wrong 3 years ago
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:06:46 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
...
Page allocator still requires interrupts to be disabled, which this doesn't.
it is
> On Tue, 13 Mar 2007 04:17:26 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 13 Mar 2007, Andrew Morton wrote:
>
> > > On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <[EMAIL
> > > PROTECTED]> wrote:
> > > Page table pages have the characteristics that they are
On Tue, 13 Mar 2007, Andrew Morton wrote:
> Yeah, prezeroing in idle is probably pointless. But I'm not aware of
> anyone having tried it properly...
Ok, then what did I do wrong 3 years ago with the prezeroing patchsets?
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 13 Mar 2007, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> > Page table pages have the characteristics that they are typically zero
> > or in a known state when they are freed.
>
> Well if they're zero then perhaps
> On Tue, 13 Mar 2007 22:06:46 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> ...
>
> >>Page allocator still requires interrupts to be disabled, which this doesn't.
> >>it is worthwhile.
> >
>
Andrew Morton wrote:
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
Page allocator still requires interrupts to be disabled, which this doesn't.
Bah. How many cli/sti statements fit into a single cachemiss?
On a Pentium 4? ;)
Sure, that is a minor detail,
> On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <[EMAIL
> >>PROTECTED]> wrote:
> >>Page table pages have the characteristics that they are typically zero
> >>or in a known state when
Andrew Morton wrote:
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed.
Well if they're zero then perhaps they should be released to the page
> On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> Page table pages have the characteristics that they are typically zero
> or in a known state when they are freed.
Well if they're zero then perhaps they should be released to the page allocator
to satisfy
V1->V2
- Add sparch64 patch
- Single i386 and x86_64 patch
- Update attribution
- Update justification
- Update approvals
- Earlier discussion of V1 was at
http://marc.info/?l=linux-kernel=117357922219342=2
This patchset introduces an arch independent framework to handle lists
of recently used
V1-V2
- Add sparch64 patch
- Single i386 and x86_64 patch
- Update attribution
- Update justification
- Update approvals
- Earlier discussion of V1 was at
http://marc.info/?l=linux-kernelm=117357922219342w=2
This patchset introduces an arch independent framework to handle lists
of recently used
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed.
Well if they're zero then perhaps they should be released to the page allocator
to satisfy the
Andrew Morton wrote:
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed.
Well if they're zero then perhaps they should be released to the page
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed.
Andrew Morton wrote:
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Page allocator still requires interrupts to be disabled, which this doesn't.
Bah. How many cli/sti statements fit into a single cachemiss?
On a Pentium 4? ;)
Sure, that is a minor detail,
On Tue, 13 Mar 2007 22:06:46 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
...
Page allocator still requires interrupts to be disabled, which this doesn't.
it is worthwhile.
If you want a
On Tue, 13 Mar 2007, Andrew Morton wrote:
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed.
Well if they're zero then perhaps they should
On Tue, 13 Mar 2007, Andrew Morton wrote:
Yeah, prezeroing in idle is probably pointless. But I'm not aware of
anyone having tried it properly...
Ok, then what did I do wrong 3 years ago with the prezeroing patchsets?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, 13 Mar 2007 04:17:26 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 13 Mar 2007, Andrew Morton wrote:
On Tue, 13 Mar 2007 00:13:25 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
Page table pages have the characteristics that they are typically zero
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:06:46 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 13 Mar 2007 19:03:38 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
...
Page allocator still requires interrupts to be disabled, which this doesn't.
it is worthwhile.
On Tue, 13 Mar 2007 04:20:48 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 13 Mar 2007, Andrew Morton wrote:
Yeah, prezeroing in idle is probably pointless. But I'm not aware of
anyone having tried it properly...
Ok, then what did I do wrong 3 years ago with the
On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
We don't actually have to zap_pte_range the entire page table in
order to free it (IIRC we used to have to, before the 4lpt patches).
I'm trying to remember why we ever would have needed to zero out the pagetable
pages if
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
We don't actually have to zap_pte_range the entire page table in
order to free it (IIRC we used to have to, before the 4lpt patches).
I'm trying to remember why we ever would have needed to zero out
On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
We don't actually have to zap_pte_range the entire page table in
order to free it (IIRC we used to have to, before the 4lpt
Andrew Morton wrote:
On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
It would be interesting to look at a) leave the page full of random garbage
if we're releasing the whole mm and b) return it straight to the page allocator.
Well we have the
Nick Piggin wrote:
However we still have to visit those to-be-unmapped parts of the page
table,
to find the pages and free them. So we still at least need to bring it
into
cache for the read... at which point, the store probably isn't a big
burden.
Why not try to find a place to stash a
On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
Nick Piggin wrote:
However we still have to visit those to-be-unmapped parts of the page
table,
to find the pages and free them. So we still at least need to bring it
into
cache for the read... at which point, the
Matt Mackall wrote:
On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
Nick Piggin wrote:
However we still have to visit those to-be-unmapped parts of the page
table,
to find the pages and free them. So we still at least need to bring it
into
cache for the
On Tue, Mar 13, 2007 at 01:17:00PM -0700, Jeremy Fitzhardinge wrote:
Matt Mackall wrote:
On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
Nick Piggin wrote:
However we still have to visit those to-be-unmapped parts of the page
table,
to find the pages and
From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 15:21:25 -0500
Because the fan-out is large, the bulk of the work is bringing the last
layer of the tree into cache to find all the pages in the address
space. And there's really no way around that.
That's right.
And I will note
On Tue, Mar 13, 2007 at 02:07:22PM -0700, David Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 15:21:25 -0500
Because the fan-out is large, the bulk of the work is bringing the last
layer of the tree into cache to find all the pages in the address
space. And
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
From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 16:14:35 -0500
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
Jeremy == Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Jeremy And do the same in pte pages for actual mapped pages? Or do
Jeremy you think they would be too densely populated for it to be
Jeremy worthwhile?
We've been doing some measurements on how densely clumped ptes are.
On 32-bit
Andrew Morton writes:
Plus, we can get in a situation where take a cache-cold, known-zero page
from the pte quicklist when there is a cache-hot, non-zero page sitting in
the page allocator. I suspect that zeroing the cache-hot page would take a
similar amount of time to a single miss agains
On Tue, Mar 13, 2007 at 04:47:56AM -0800, Andrew Morton wrote:
I'm trying to remember why we ever would have needed to zero out the
pagetable pages if we're taking down the whole mm? Maybe it's
because oh, the arch wants to put this page into a quicklist to
recycle it, which is all rather
58 matches
Mail list logo
