Also on a generic note, how come we have 4 spare bits in the PTE for 64bit
> address space? Large pages perhaps?
We don't exploit the entire 64-bit address space. Up until recently we
only gave 16T to processes though we just bumped that a bit.
Chee
age in context:
http://linuxppc.10917.n7.nabble.com/Understanding-how-kernel-updates-MMU-hash-table-tp59509p67313.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
I cannot see my post at all on the old nabble system...this is just for
testing purposes//...
My last post is fine..but I cannot see my thread on linuxppc-dev@oldnabble
...?? :confused:
--
View this message in context:
http://old.nabble.com/Understanding-how-kernel-updates-MMU-hash-table
quot;?
Is it the encoding of the HPTE address in the LPTE as mentioned above? Or
some aspect of ppc64 that I am unaware of? :thinking:
Also on a generic note, how come we have 4 spare bits in the PTE for 64bit
address space? Large pages perhaps?
--
View this message in context:
On Sat, 2012-12-08 at 23:18 -0800, Pegasus11 wrote:
> 3. For 64bit architecture there is no such 'segment register we use a
> segment table entry (STE) from within an SLB (segment lookaside buffer)
> which caches recently used mappings from ESID (part of effective address) to
> VSID (part of Virtua
> argument.
> >
> > That vaddr is necessary to locate the corresponding hash entries and to
> > perform TLB invalidations if needed.
> >
> >> >> So if it indeed the later, what trickery are we here after? Perhaps
> &
On Wed, 2012-12-05 at 23:57 -0800, Pegasus11 wrote:
> Hi Ben.
>
> Got it..no more quoting replies...
Quoting is fine ... as long as you quote the bits your reply to, not
your actual reply part :)
> You mentioned the MMU looking into a hash table if it misses a translation
> entry in the TLB. Thi
ges
>> >> preceding the page which holds the address of PTEP. Then we get the
>> lower
>> >> 12
>> >> bits of this page. Then we shift that these bits to the left by 12
>> again
>> >> and
>> >> to it we add the above index. Wha
On Wed, 2012-12-05 at 09:14 -0800, Pegasus11 wrote:
> Hi Ben.
>
> Thanks for your input. Please find my comments inline.
Please don't quote your replies ! Makes it really hard to read.
>
> Benjamin Herrenschmidt wrote:
> >
> > On Tue, 2012-12-04 at 21:56 -0800, Pegasus11 wrote:
> >> Hello.
> >
t you do know the higher ups..and the
> way those baldies think now don't u? Its hard as such to work with
> them..helping them to a platter of such goodies would only mean that one
> is trying to undermine them (or so they'll think)...So Im between a rock
> a
On Tue, 2012-12-04 at 21:56 -0800, Pegasus11 wrote:
> Hello.
>
> Ive been trying to understand how an hash PTE is updated. Im on a PPC970MP
> machine which using the IBM PowerPC 604e core.
Ah no, the 970 is a ... 970 core :-) It's a derivative of POWER4+ which
is quite different from the old 32-
View this message in context:
http://old.nabble.com/Understanding-how-kernel-updates-MMU-hash-table-tp34760537p34760537.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
12 matches
Mail list logo
