Re: [Lse-tech] Re: Examining the Performance and Cost of Revesema ps on 2.5.26 Under Heavy DBWorkload

[Hubertus Franke <frankeh@watson.ibm.com>]

On Tuesday 17 September 2002 05:47 pm, William Lee Irwin III wrote:
> At some point in the past, Tony Luck wrote:
> >> Can't you use LD_PRELOAD tricks to sneak a different version
> >> shmget/shmat to your DB2 binary so that you can intercept the important
> >> calls and divert them to use huge tlb pages?
>
> On Tue, Sep 17, 2002 at 02:42:31PM -0700, Martin J. Bligh wrote:
> > If we had a shmget/shmat call that supported large pages, that would
> > probably make it easier ? ;-) That's the whole issue - large pages aren't
> > supported with standard syscalls, so every app is required to rewrite
> > their memory handling, which isn't going to happen.
> > M.
>
> The pressure on this never lets up. It's being done, though I can't say
> I'm entirely happy with how quickly/slowly I'm getting it done myself.
>
>
> Bill

Yes, its feasible to do the LD_PRELOAD. But Martin is right.
If the large page is the proper concept, than it should be supported
in the base kernel concept, not through some wirdo off the beaten 
path stuff. Non-trivial but possible.

I have been talking with Bill.

One should conceptually distinguish (as we already did in the discussions 7 
weeks ago) that there are two benefits to large pages
(a) TLB miss reduction
(b) larger possible I/O  (page clustering)

The concept can be merged, but for x86 we got   4K vs. 4M which doesn't really
warrant the I/O question.
If more diverse TLB sizes are supported as on other architectures that it 
makes sense to support through the base kernel multiple page sizes, and
if one of the page sizes supported overlaps with a TLB entry size we also
get the benefit for (a).

In case that the TLB size is insanely large like for IA64 (2GB ?) then one
can fallback to the Intel-HugeTLB patch solution, but for the general
consumption that doesn't make sense.


-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)
--
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/