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

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

[Luck, Tony, Martin]

> > That's a ton of memory.  Where do we stand wrt getting these
> > applications to use large-tlb pages?
> 
> We need standard interfaces (like shmem) to get DB2 to port, and probably 
> most other applications. Having magic system calls is all very well in
theory,
> but not much use in practice. 
> 
> And yes, we're still working on it.

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?

-Tony
--
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/

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

[Martin J. Bligh]

>> > That's a ton of memory.  Where do we stand wrt getting these
>> > applications to use large-tlb pages?
>> 
>> We need standard interfaces (like shmem) to get DB2 to port, and probably 
>> most other applications. Having magic system calls is all very well in
> theory,
>> but not much use in practice. 
>> 
>> And yes, we're still working on it.
> 
> 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?

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.


--
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/

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

[William Lee Irwin III]

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
--
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/

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

[Martin J. Bligh]

>>> 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.

Sorry, I wasn't trying to harrass you - was trying to emphasize how important
it is that this gets accepted once it's complete.

M.

--
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/

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

[Hubertus Franke]

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/