[OT] Better JSP Performance with Opteron

[Leon Rosenberg <ro...@googlemail.com>]

Hi,

recently I found (ok actually our sysadmin did) this articles on the
web, and wanted to share some thoughts.

http://www.devx.com/amd/Article/30529
http://www.devx.com/amd/Article/30785

The article describes, that using opteron and large memory pages can
give significant performance wins. I don't doubt this, but I doubt,
that large memory pages are a real use case in the tomcat / java
webapps world. At least in applications I saw there are always many
small objects, tags, beans, dtos.

any other thoughts?

regards
Leon

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Better JSP Performance with Opteron

[Rainer Jung <to...@kippdata.de>]

Leon Rosenberg wrote:
> Ok, my fault,
> read "page" and "java" in one sentence -> map to Java Page -> Java
> Server Page. Must be a circuit error in the brain.
> Anyway, does it mean, that a proper configured JVM on an opteron
> processor, will be significantly faster? Could be very interesting for
> caches...

It depends on the number of memory pages your memory controller has to 
manage. I don't know the details about Opteron TLB (and didn't read the 
article carefully enough). So if your working set size is small I doubt 
any positive impact. If you use large memory/CPU the difference might be 
noticable.

Modern CPUs have on chip performance counters to find out. I know, that 
at least from a SPARC chip you can get the number of TLB misses from on 
chip performance registers (using cpustat/cputrack under Solaris). 
cpustat works for Opteron on Solaris 10 x86 too. Under Linux there seems 
to be perfctr patches (see: 
http://www.rz.rwth-aachen.de/computing/events/2006/sunhpc_2006/05_Smith.ppt)

Opteron has a lot of performance counters. You will find the ones 
supported by cpustat on

http://opensolaris.org/os/community/observability/hardware/cpc/

> Leon
> 
> On 4/3/06, Rainer Jung <to...@kippdata.de> wrote:
>> Using large pages to eliminate TLB misses has nothing to do with the
>> size of the objects. From the view of the operating system java heap is
>> just a huge and continuous chunk of memory. Anything what's inside is
>> managed by the JVM. But whenever the JVM needs to access an adress it
>> needs to make an address calculation as described in the article. Once
>> the needed adress translation tables do not fit into the TLB,
>> performance gets bad. Since Java often uses a large and continuous heap
>> it's a very good candidate for using large pages, saving entries in the TLB.
>>
>> Leon Rosenberg wrote:
>>> Hi,
>>>
>>> recently I found (ok actually our sysadmin did) this articles on the
>>> web, and wanted to share some thoughts.
>>>
>>> http://www.devx.com/amd/Article/30529
>>> http://www.devx.com/amd/Article/30785
>>>
>>> The article describes, that using opteron and large memory pages can
>>> give significant performance wins. I don't doubt this, but I doubt,
>>> that large memory pages are a real use case in the tomcat / java
>>> webapps world. At least in applications I saw there are always many
>>> small objects, tags, beans, dtos.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Better JSP Performance with Opteron

[Nikola Milutinovic <al...@yahoo.com>]

--- Leon Rosenberg <ro...@googlemail.com> wrote:

> Ok, my fault,
> read "page" and "java" in one sentence -> map to Java Page -> Java
> Server Page. Must be a circuit error in the brain.
> Anyway, does it mean, that a proper configured JVM on an opteron
> processor, will be significantly faster? Could be very interesting for
> caches...
> 
> Leon
> 
> On 4/3/06, Rainer Jung <to...@kippdata.de> wrote:
> > Using large pages to eliminate TLB misses has nothing to do with the
> > size of the objects. From the view of the operating system java heap is
> > just a huge and continuous chunk of memory. Anything what's inside is
> > managed by the JVM. But whenever the JVM needs to access an adress it
> > needs to make an address calculation as described in the article. Once
> > the needed adress translation tables do not fit into the TLB,
> > performance gets bad. Since Java often uses a large and continuous heap
> > it's a very good candidate for using large pages, saving entries in the

Hmmm, Im not sure about this.

I do agree that a page size too small will make a heavy use of CPU/OS internal
structures, resulting in poor performance. OTOH, using a page size too big
results in degradation of effectiveness of that processes working set. Suppose
a whole block of 1 MB was out of the TLB or swapped out. Operating on a
relatively small, well grouped memory region, would result in the whole 1 or 2
MB of memory be introduced into the active set, instead of just those "smaller
pages".

Of course, having portions of your memory collect dust, could be a sign of poor
programming, memory leaks and what not. You mileage may vary. Setting a page
size to 2 MB may be a bit extreme. If it can be set to just one process and
dynamically, or at least at startup, that would be coll. Somehow, I doubt this
level of flexibility exists. You may spead up your JVM, but slow down the rest
of the system. Again, YMMV. This should be put to a test.

Nix.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Better JSP Performance with Opteron

[Leon Rosenberg <ro...@googlemail.com>]

Ok, my fault,
read "page" and "java" in one sentence -> map to Java Page -> Java
Server Page. Must be a circuit error in the brain.
Anyway, does it mean, that a proper configured JVM on an opteron
processor, will be significantly faster? Could be very interesting for
caches...

Leon

On 4/3/06, Rainer Jung <to...@kippdata.de> wrote:
> Using large pages to eliminate TLB misses has nothing to do with the
> size of the objects. From the view of the operating system java heap is
> just a huge and continuous chunk of memory. Anything what's inside is
> managed by the JVM. But whenever the JVM needs to access an adress it
> needs to make an address calculation as described in the article. Once
> the needed adress translation tables do not fit into the TLB,
> performance gets bad. Since Java often uses a large and continuous heap
> it's a very good candidate for using large pages, saving entries in the TLB.
>
> Leon Rosenberg wrote:
> > Hi,
> >
> > recently I found (ok actually our sysadmin did) this articles on the
> > web, and wanted to share some thoughts.
> >
> > http://www.devx.com/amd/Article/30529
> > http://www.devx.com/amd/Article/30785
> >
> > The article describes, that using opteron and large memory pages can
> > give significant performance wins. I don't doubt this, but I doubt,
> > that large memory pages are a real use case in the tomcat / java
> > webapps world. At least in applications I saw there are always many
> > small objects, tags, beans, dtos.
> >
> > any other thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Better JSP Performance with Opteron

[Rainer Jung <to...@kippdata.de>]

Using large pages to eliminate TLB misses has nothing to do with the 
size of the objects. From the view of the operating system java heap is 
just a huge and continuous chunk of memory. Anything what's inside is 
managed by the JVM. But whenever the JVM needs to access an adress it 
needs to make an address calculation as described in the article. Once 
the needed adress translation tables do not fit into the TLB, 
performance gets bad. Since Java often uses a large and continuous heap 
it's a very good candidate for using large pages, saving entries in the TLB.

Leon Rosenberg wrote:
> Hi,
> 
> recently I found (ok actually our sysadmin did) this articles on the
> web, and wanted to share some thoughts.
> 
> http://www.devx.com/amd/Article/30529
> http://www.devx.com/amd/Article/30785
> 
> The article describes, that using opteron and large memory pages can
> give significant performance wins. I don't doubt this, but I doubt,
> that large memory pages are a real use case in the tomcat / java
> webapps world. At least in applications I saw there are always many
> small objects, tags, beans, dtos.
> 
> any other thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org