Linus Torvalds wrote:
> On Fri, 16 Nov 2007, Jeremy Fitzhardinge wrote:
>
>> If you happened to do a 1G munmap, it may end up freeing and
>> reallocating them, but that's going to be very rare.
>>
>
> I don't think we ever free the pmd's now, do we?
>
> (Except for the *final* free, of cou
On Fri, 16 Nov 2007, Jeremy Fitzhardinge wrote:
>
> If you happened to do a 1G munmap, it may end up freeing and
> reallocating them, but that's going to be very rare.
I don't think we ever free the pmd's now, do we?
(Except for the *final* free, of course, when we release the whole VM).
Linus Torvalds wrote:
> So don't do it. Just preallocate for the magic 4-entry PGD. You can make
> the special case just be something like
>
Yes, OK, it makes sense. Conceptually they would be dynamically
allocated and freed, but they'd just happen to start allocated, to avoid
the tlb flush o
Linus Torvalds wrote:
> On Fri, 16 Nov 2007, Jeremy Fitzhardinge wrote:
>
>>> IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
>>> have to be present.
>>>
>> Hm, do you recall what processors that might affect? As far as I know,
>> current processors will ignore n
Jeremy Fitzhardinge wrote:
Hm, do you recall what processors that might affect? As far as I know,
current processors will ignore non-present top-level entries. Anyway,
we can point them not present to empty_zero_page, so testing the present
bit will still be sufficient to tell if we need to al
On Fri, 16 Nov 2007, Jeremy Fitzhardinge wrote:
> >
> > IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
> > have to be present.
>
> Hm, do you recall what processors that might affect? As far as I know,
> current processors will ignore non-present top-level entries.
Ar
Linus Torvalds wrote:
> On Thu, 15 Nov 2007, Jeremy Fitzhardinge wrote:
>
>> Once difference is that 64-bit incrementally allocates all levels of the
>> pagetable, whereas 32-bit PAE preallocates the 4 pmds when it allocates
>> the pgd. What's the rationale for this? What pitfalls would there
Andi Kleen wrote:
On Friday 16 November 2007 16:45:16 H. Peter Anvin wrote:
Andi Kleen wrote:
I think Jeremy's question was due to trying to reduce the 32/64-bit
differences. Performance-wise, it might add a small amount to user
setup time (a typical 32-bit process will need all four, for the
On Friday 16 November 2007 16:45:16 H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> I think Jeremy's question was due to trying to reduce the 32/64-bit
> >> differences. Performance-wise, it might add a small amount to user
> >> setup time (a typical 32-bit process will need all four, for the mai
Andi Kleen wrote:
I think Jeremy's question was due to trying to reduce the 32/64-bit
differences. Performance-wise, it might add a small amount to user
setup time (a typical 32-bit process will need all four, for the main
binary, libraries, stack and kernel, respectively)
With the new top
> I think Jeremy's question was due to trying to reduce the 32/64-bit
> differences. Performance-wise, it might add a small amount to user
> setup time (a typical 32-bit process will need all four, for the main
> binary, libraries, stack and kernel, respectively)
With the new top down mmap l
William Lee Irwin III wrote:
There may be bigger fish to fry in terms of per-process overhead, if
you're trying to cut that down. The trouble with trying to address
some of those is that there is mutual antagonism between compactness
and expansibility in the process address space layout, so you'
Linus Torvalds wrote:
>> IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
>> have to be present.
On Thu, Nov 15, 2007 at 02:42:46PM -0800, H. Peter Anvin wrote:
> This is true, although you could point a PGD to an all-zero page if you
> really wanted to. You have to re-lo
Linus Torvalds wrote:
IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
have to be present.
This is true, although you could point a PGD to an all-zero page if you
really wanted to. You have to re-load CR3 after modifying the top-level
entries.
What earlier CPU's
On Thu, 15 Nov 2007, Jeremy Fitzhardinge wrote:
>
> Once difference is that 64-bit incrementally allocates all levels of the
> pagetable, whereas 32-bit PAE preallocates the 4 pmds when it allocates
> the pgd. What's the rationale for this? What pitfalls would there be
> in making them increme
I'm looking at unifying asm-x86/pgalloc*.h, and so I'm trying to make
things as similar as possible between 32 and 64-bit.
Once difference is that 64-bit incrementally allocates all levels of the
pagetable, whereas 32-bit PAE preallocates the 4 pmds when it allocates
the pgd. What's the rationale
16 matches
Mail list logo
