[RFC] [PATCH 0/5 V2] Huge page backed user-space stacks

[Michael Ellerman]

On Thu, 2008-07-31 at 14:50 +0100, Mel Gorman wrote:
> On (31/07/08 21:51), Nick Piggin didst pronounce:
> > On Thursday 31 July 2008 21:27, Mel Gorman wrote:
> > > On (31/07/08 16:26), Nick Piggin didst pronounce:
> > 
> > > > I imagine it should be, unless you're using a CPU with seperate TLBs for
> > > > small and huge pages, and your large data set is mapped with huge pages,
> > > > in which case you might now introduce *new* TLB contention between the
> > > > stack and the dataset :)
> > >
> > > Yes, this can happen particularly on older CPUs. For example, on my
> > > crash-test laptop the Pentium III there reports
> > >
> > > TLB and cache info:
> > > 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
> > > 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries
> > 
> > Oh? Newer CPUs tend to have unified TLBs?
> > 
> 
> I've seen more unified DTLBs (ITLB tends to be split) than not but it could
> just be where I'm looking. For example, on the machine I'm writing this
> (Core Duo), it's
> 
> TLB and cache info:
> 51: Instruction TLB: 4KB and 2MB or 4MB pages, 128 entries
> 5b: Data TLB: 4KB and 4MB pages, 64 entries
> 
> DTLB is unified there but on my T60p laptop where I guess they want the CPU
> to be using less power and be cheaper, it's
> 
> TLB info
>  Instruction TLB: 4K pages, 4-way associative, 128 entries.
>  Instruction TLB: 4MB pages, fully associative, 2 entries
>  Data TLB: 4K pages, 4-way associative, 128 entries.
>  Data TLB: 4MB pages, 4-way associative, 8 entries

Clearly I've been living under a rock, but I didn't know one could get
such nicely formatted info.

In case I'm not the only one, a bit of googling turned up "x86info",
courtesy of davej - apt-get'able and presumably yum'able too.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080801/e1cabf70/attachment.pgp>